Whats the point of memory locations?

[Sentinel]

Why in programming is there so much emphasis on where the variable is stored in memory? And is that RAM memory?

 

[tfinch2]

...i'm not even gonna touch this thread with a 10 ft poll. but yes it is RAM.

 

[Sentinel]

lol well its not like i dont get flamed every other day for asking simple questions

 

[notfred]

Think of memory like a filing cabinet. When a program creates a variable, it creates a new folder and puts it in the filing cabinet. When it needs to access the variable, it goes and gets the folder it created.

These folders aren't labeled. The only way to look up a folder is by location. I.E., you're getting the folder in the top drawer, third from the front.

You see why it's important to keep track of memory locations now?

 

[CTho9305]

I don't think I understand exactly what your question is. Who places emphasis on where a variable is stored, and in what way is this person placing emphasis on it?

 

[tfinch2]

Originally posted by: notfred
Think of memory like a filing cabinet. When a program creates a variable, it creates a new folder and puts it in the filing cabinet. When it needs to access the variable, it goes and gets the folder it created.

These folders aren't labeled. The only way to look up a folder is by location. I.E., you're getting the folder in the top drawer, third from the front.

You see why it's important to keep track of memory locations now?

plus inefficient programming creates too big of a memory footprint

 

[warcrow]

...give the guy a break. He's curious and wants to know. Whats the big deal?

 

[Sentinel]

yeah that makes more sense, i just wondered for my programming class.

 

[zodder]

Originally posted by: Sentinel
lol well its not like i dont get flamed every other day for asking simple questions

lmao!

 

[DT4K]

Define "emphasis".
The point of memory locations is that you can't get data if you don't know where it is.
Now whether you actually care or place "emphasis" on what the actual location is depends on what language you are using and what kind of programming you are doing.

Are you asking why they teach you about memory addresses, stack, heap, etc., when for most programming, all you do is declare a variable name and use that without caring where the value is stored?

If so, I'd say it's because you will be a better programmer if you understand what is going on under the hood. You may never particularly care whether your variable is being stored on the stack or the heap or what the memory address is, but understanding this can help you decide the most efficient way to program something.

 

[kamper]

I think the overwhelming trend is taking the emphasis off where the variable is stored in memory. The first major step towards this is virtual memory which is obviously designed to make the true memory location irrelevant.

The second is variables as symbols. You declare "int c = 3;" and you don't give a crap what the virtual address of c is. This would be in contrast to saying something like "0x00ff = 3", in which case you need to know exactly what the address is. Granted, for a language like C it is still crucial to understand the difference between the stack and the heap but you could argue that that is just a limitation of the language (but I won't argue that, for fear that all the xml-hatin unix programmers will come kick my ass ).

Third step: when you get to a higher level language the need to understand this is largely alleviated, especially for a language with a garbage collector. I'll use java because that's what I know best. In java only primitives and references are stored on the stack and since you can never use references to primitives or references to references you will never have a reference or variable go wrong. Hence, you don't technically need to know the difference between the stack and the heap. Contrast that to C and trying to return a pointer to a local int: that reference becomes invalid as soon as the method returns.

The less you need to know about memory addresses, the easier programming gets. Let the hardware/operating system/compiler/runtime environment take care of it for you. I'm not advocating not learning about memory addresses, that's still beneficial, but the less the logic of your program is concerned with it the better.

 

[Sentinel]

wow. thanks for the input.

i learned python last year, now im in a c++ class and I didnt remember having to learn about memory locations etc.

 

[CTho9305]

I think the overwhelming trend is taking the emphasis off where the variable is stored in memory. The first major step towards this is virtual memory which is obviously designed to make the true memory location irrelevant.

Virtual memory is largely irrelevant to this discussion, as you write code exactly the same way with and without it. Only an OS writer or hardware designer really worries about that abstraction.

 

[Barnaby W. Füi]

Originally posted by: Sentinel
wow. thanks for the input.

i learned python last year, now im in a c++ class and I didnt remember having to learn about memory locations etc.

There's no real reason to do so in python, but they're definitely there:

% python
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class foo: pass
...
>>> foo()
<__main__.foo instance at 0x4020c9cc>

 

[kamper]

Originally posted by: CTho9305

I think the overwhelming trend is taking the emphasis off where the variable is stored in memory. The first major step towards this is virtual memory which is obviously designed to make the true memory location irrelevant.

Virtual memory is largely irrelevant to this discussion, as you write code exactly the same way with and without it. Only an OS writer or hardware designer really worries about that abstraction.

That's my point. Someone at some level has fewer worries because of it. It's the first in a number of layers that save someone from having to know a precise physical memory address. I know he didn't say "in os/compiler design" but neither did he say "in c programming" or "in higher-level-language-than-c programming". He didn't ask a specific question so I thought I'd try to give him the big picure as I best as I understand it.

 

[Sentinel]

good call, all i was asking is a general answer to a general question

 

[CTho9305]

Originally posted by: kamper

Originally posted by: CTho9305

I think the overwhelming trend is taking the emphasis off where the variable is stored in memory. The first major step towards this is virtual memory which is obviously designed to make the true memory location irrelevant.

Virtual memory is largely irrelevant to this discussion, as you write code exactly the same way with and without it. Only an OS writer or hardware designer really worries about that abstraction.

That's my point. Someone at some level has fewer worries because of it. It's the first in a number of layers that save someone from having to know a precise physical memory address. I know he didn't say "in os/compiler design" but neither did he say "in c programming" or "in higher-level-language-than-c programming". He didn't ask a specific question so I thought I'd try to give him the big picure as I best as I understand it.

What I'm saying is that even without Virtual Memory, you, as a C or C++ coder, don't have to worry about the actual physical memory location*. The only time you have to worry about it is when you're actually implementing the virtual memory code for an OS. Outside of a very small part of the kernel, you won't really be able to tell the difference (outside, as in the rest of the kernel and all userspace apps).

*as long as you don't use more memory than is available .

 

[kamper]

Originally posted by: CTho9305
What I'm saying is that even without Virtual Memory, you, as a C or C++ coder, don't have to worry about the actual physical memory location*. The only time you have to worry about it is when you're actually implementing the virtual memory code for an OS. Outside of a very small part of the kernel, you won't really be able to tell the difference (outside, as in the rest of the kernel and all userspace apps).

*as long as you don't use more memory than is available .

I agree with you BUT he hadn't yet said what programming he was doing. Ok, that's a weak argument; I could have guessed that he wasn't implementing a vm system

Although, my point was also that, although you don't need to know about the underlying layers, knowing about them is never bad and can make you a better programmer. I was trying to be helpful. Please don't gripe at me because I included more information than was strictly necessary