P-1.2 Memory, Addresses and What a Variable Really Is

What this is and why it exists

A variable is usually taught as a box with a name on it. That picture is close enough to write a first program and wrong enough to make pointers, references, copying and every memory defect incomprehensible later.

So replace it now, while it is cheap. A variable is a name your language keeps for a location and a size, plus an agreement about how to read the bits stored there.

The other half of this topic is where things live. Almost every later confusion about lifetimes, copying and leaks traces back to not knowing whether something is on the stack or the heap.

The vocabulary

• Byte — the unit memory is counted in.
• Address — the number identifying one byte's position.
• Variable — a name kept by your language for an address, a size, and a type.
• Type — the agreement about how to interpret the bits at that address.
• Stack — automatic storage that grows and shrinks as functions are called and return.
• Heap — storage you ask for explicitly, which lives until it is given back.
• Reference — a value that is the address of something else.
• Lifetime — the span during which a stored value is valid to use.

The mental model

Main memory is one very long row of bytes, each with a number called its address. Nothing in that row is labelled. There are no names in memory. Every name in your program is a convenience your language maintains on top of plain numbering.

Storing a value means writing bytes at some address and remembering two things: how many bytes, and how to interpret them. That second part is the type, and it matters more than it looks. The same eight bytes are a number or a piece of text depending only on what your program says they are. Nothing in the bytes themselves says which.

Now, where things live. Local values go on the stack, a region that grows when a function is called and shrinks when it returns. This is why locals cost almost nothing to create: the machine moves one marker. It is also why keeping hold of one after its function has returned is a defect. The storage is not yours any more; it will be handed to the next call.

The heap is the other region, and you go there for two reasons. The value has to outlive the function that created it. Or its size is not known until the program runs. You ask for heap storage explicitly and you are responsible for giving it back. Everything about memory leaks and use-after-free lives here, and the two are one problem seen twice. One is forgetting to return storage. The other is using it after you have.

Finally, copying. Passing a small number to a function usually copies the number. Passing a large structure usually copies only its address. That single difference decides whether a change made inside a function is visible outside it. It is one of the commonest sources of surprise in a first year of programming. It is not a mystery about the function; it is a question about what was handed over.

What you should now be able to explain or do

Describe memory as numbered bytes with nothing labelled. Say what a variable is in terms of an address, a size and a type. Explain why the same bytes can be two different things. Say what the stack is for and why a local value must not be used after its function returns. Say what the heap is for and name the two failures that live there. Explain why a change inside a function is sometimes visible outside it and sometimes not.

Check yourself