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?
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.
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.
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 thetype_info
structure available viatypeid
).Otherwise, all the type information is static.
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.