Where are the variable/reference names or types stored in memory for stack/heap variables?

1.8k views Asked by At

I think I understand the main difference between stack and heap.

In the following program, an Object of size n is created on the heap. A pointer p refering to this sofar nameless object is created on the stack, where it occupies 4 bytes (at least on my system). If I understood well, as references do not use extra memory, no further memory is allocated (except maybe for the int returned by main() on the stack).

Class Object;  // n bytes

int main() {
    Object* p = new Object();
    Object& r = *p;
    // ...
}

Still, the memory management is not fully clear yet:

1) where are the names p and r stored? They are both local names, so I suppose they should also go on the stack? Does this not require extra memory to store the binding between a variable name and the part of memory it refers to?

2) where is the type of the pointer stored? The pointer occupies only 4 bytes on the stack, which (I think) is the exact size to store a memory address. How does the computer know which type can be found at that address?

3) similarly to (2), the Object on the heap needs n bytes of storage and the only (direct) reference to it 0 bytes. Where is the type of this object stored, so when r is used, it knows which type it is?

4) I understood that the compiled program also resides in memory somewhere to guide execution of it. Is this on the stack or the heap, or is this still another part of the memory?

3

There are 3 answers

4
Mike Seymour On BEST ANSWER

where are the names p and r stored?

They aren't - variable names are static, and not available at runtime. The compiler knows where the variables will be stored, and generates code to access that memory location without any need for a name.

They might be available in a special debugging section of the program file, to allow a debugger to display the variables' values.

where is the type of the pointer stored?

It isn't - types are also static (except for limited dynamic type information associated with polymorphic class types, but not pointer types). The compiler knows the type, and generates code to access the stored value in the correct way for that type.

Where is the type of this object stored?

If the type is polymorphic (i.e. if it's a class type with at least one virtual function), then there will be some static data, stored in an unspecified place that you can't directly access, to describe the type. There will be enough data to support virtual function calls (typically a table of pointers to the final overrides) and RTTI (a specification of the inheritance structure for use by dynamic_cast, and the type_info structure available via typeid).

Otherwise, all the type information is static.

Is [the compiled program] on the stack or the heap, or is this still another part of the memory?

On a typical computer, it's in static memory (a code or text section), loaded when the program starts. On embedded systems, it might instead be located more permanently in read-only memory.

0
Tony Delroy On

as references do not use extra memory, no further memory is allocated

How references are implemented is not specified in the C++ Standard, but most compilers would implement them much like pointers, so in unoptimised code there'd probably be another 4 bytes (on your system) for r....

where are the names p and r stored

here is the type of the pointer stored?

Where is the type of [r] stored

They exist inside the compiler itself while its running, and perhaps in some debugging symbol information put into the generated objects/libraries/program to help interactive debugging if you use e.g. GCC's g++ -g option, but they're not stored or accessible through normal C++ program statements.

I understood that the compiled program also resides in memory somewhere to guide execution of it. Is this on the stack or the heap, or is this still another part of the memory?

The compiled program is a bunch of binary data and machine code opcodes (numbers) that the Operating System knows how to load and ask the CPU to interpret and execute. That data for that is not normally on the stack nor heap, but in a mixture of "uninitialised data", "initialised data" and "code" segments/areas that the Operating System arranges.

0
Min Fu On

Computers never know p and r. Variable names are used to improve readability in high-level languages. For example, you can get the assembly code via

gcc -S -c code.c

There are not p and r at all in code.s