Memory

Every variable introduced in programming fundamentals actually lives somewhere specific inside the RAM the first topic in this series described, and that specific location is called an address — a plain number, often written in hexadecimal exactly as covered in data representation, that identifies one particular spot in memory. A pointer (sometimes called a reference) is a variable that holds an address instead of holding a value directly, which is the real, physical mechanism underneath the relations covered in discrete mathematics: when the filesystem tree's "contains" edges connect a folder to the files inside it, a pointer stored in memory is literally what makes that connection, one address pointing at the location of the next item. The stack is the region of memory used automatically for function calls: every time `calculate_total_size` is called, a new stack frame is created to hold its local variables like `total` and the current loop entry, and when the function returns, that entire frame is thrown away automatically, in the exact reverse order the frames were created — fast, predictable, and requiring no manual cleanup at all. The heap is different: it's memory that has to persist beyond any single function call, so it's requested and released explicitly rather than being cleaned up automatically, which is where something like a list of file entries would actually live if a program needed that list to still exist after the function that built it had already returned. Object lifetime is the span of time a piece of memory remains valid, and the stack and heap handle this in opposite ways: a stack variable's lifetime ends automatically the instant its function returns, while a heap object's lifetime lasts until something explicitly releases it — and getting that second case wrong produces two of the most common bugs in all of programming, exactly the kind the previous topic's tracing and assertions are built to catch: a memory leak happens when heap memory is never released even though nothing needs it anymore, slowly wasting more and more RAM, while a dangling pointer happens when memory is released but something still holds its old address and tries to use it anyway, reading or writing to a location that may now hold something completely different. None of this complexity exists for ordinary local variables, which is exactly why the stack's automatic, predictable lifetime is preferred whenever it's sufficient, and the heap, with all its manual bookkeeping, is reserved for the specific cases — like data that needs to outlive the function that created it — where the stack genuinely cannot do the job.