In what practical ways is it good to remember the memory/pointers model? [closed]

Question

A variable refers to a value. A variable is also stored in a memory address. People say that it's good to have this memory model in mind. Is that true? What is some sample code that shows this as beneficial in practice?

You dont have to use programming, you can use a real-world analogy if you like.

edit: they keep removing the helpful answer i summed up here -- no idea why

Answer 1

Many modern programming environments are managed environments: they have automatic memory management, which means that you don’t have to worry about memory allocation and deallocation.

They replace the concept of memory and pointers with higher-level concepts such as local variables, fields, “references”, etc. You are now supposed to think of a local variable as some abstract storage location. You no longer have to worry about where in memory that location is and what you need to do with it in order for it to clean up correctly — that is abstracted away — but you do still need to worry about the high-level properties of the abstraction, like, say, the fact that assigning to a local variable obliterates its previous value.

Many experienced programmers who understand the whole system very well, have trouble separating this abstract higher level from the concrete lower level. For example they might directly think of a local variable as a memory location within the stackframe. Consequently, they perceive low-level details as more important than they are because they cannot imagine someone using local variables without understanding the stackframe. Personally I feel that such people make programming harder for newbies than it needs to be, both by complicating explanations of the higher-level concepts, and also by expecting newbies to find the low-level details important. Programming is all about abstraction and this is a very useful abstraction. (It doesn’t help that C’s/C++’s abstraction of local variables is really rather leaky, which makes some of the low-level details more important than they are in managed environments.)

This is not to say that we can all forget everything we know about pointers and stackframes and never teach it. Certainly if you’re interested in it then you should learn about it and broaden your understanding. You can occasionally benefit from the knowledge even when writing high-level code that doesn’t strictly require it (e.g. when optimizing it), and you certainly need it if you’re writing the memory management itself (e.g. a garbage collector). But you definitely shouldn’t feel that you can never be a “proper” programmer without understanding every last low-level detail. Even people who understand the stackframe may forget (or not know) that some local variables may be stored in a register instead. Even people who know about that may not know about the physical circuitry that makes up a register. We all use abstractions to make it easier to reason about our programs so we don’t have to go all the way down to electrons in silicon all the time.

Answer 2

I believe your question is not worded in a way that actually makes sense. I think what you're really asking is, "Is it good to understand memory and pointers."

Say in C++ we have a class Dog.

Dog a = Dog();  // On stack
Dog *b = new Dog();  // On heap.

'a' holds a value which is a Dog.

'b' holds a value that is a memory address that is on the heap (which we will find a dog hiding there).

'b' takes up space on the stack to hold the address so it'll only take up the size of a pointer on the stack.

'a' takes up space on the stack which is the size of a dog.

Say we want the dogs to bark now though...

a.bark();
b->bark();

We have to treat our dogs differently.

b->bark();
(*b).bark(); // same as above

We have to say, "Go to where b lives, and tell it to bark." Most people don't get the difference and want to say.

b.bark();  // Won't work, might not even build.

Because a pointer is just an location (which is just a number). And a number cannot bark. ('a' is a Dog. 'b' is the location of another dog.)

// We can even change what dog b points to.
b = &a;  // b will now hold the location to dog 'a'.
         // we will also have a dog that shall be lost forever D=!
b->bark();
a.bark();  // dog 'a' has now barked twice in a row since b points to a.

Do you need to understand this? Depends on what languages and tools you use. In languages like Java and Python all of this is forced on you without you knowing it, it's handled by the language so you don't notice it.

Is it good to understand this? Why yes... yes it is.

Do you have to keep it active in your mind? Well... lets allocate an array.

int stackArray[INT_MAX];  // Probably overflows the stack
int *heapArray = new int[INT_MAX];  // Allocates it all on the heap
                                    // or returns NULL if it cannot find the space.

So yes. At times.

(stackArray will actually be a pointer though... to memory on the stack)

Answer 3

In Java, if you store an object in a variable like

MyClass myObject = new MyClass();

Then myObject contains only a reference to the actual object, which resides in the memory. And if you do this:

MyClass anotherObject = myObject;

Then anotherObject contains the reference to the same object like myObject. There is only one object in the memory and both variables point to it. If you change something on myObject or on anotherObject, both will affect the same. So even in Java it is useful to keep in mind that you deal at least with references.