Where are the variables / reference names or types stored in memory for the stack / heap variables?
I think I understand the main difference between stack and heap.
The following program creates an object of size n on the heap. A pointer p is created on the stack referencing this win-win sofar object where it takes 4 bytes (at least on my system). If I understood well, since references do not use extra memory, no extra 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;
// ...
}
However, memory management is not completely clear yet:
1) where are the names p and r stored? They are both local names, so I suppose they should go to the stack as well? Does it require additional memory to store the binding between the variable name and the portion of memory it refers to?
2) where is the pointer type stored? The pointer only takes 4 bytes on the stack, which (I think) is the exact size to store the memory address. How does the computer know which type can be found at this address?
3) similarly to (2), an object in the heap needs n bytes of storage and a single (direct) reference to it is 0 bytes. Where is the type of this object stored, so when r is used it knows which type it is?
4) I realized that the compiled program is also somewhere in memory to execute it. Is it on the stack or heap, or is it just another piece of memory?
source to share
where are the names p and r stored?
They are not - 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 the need for a name.
They can be accessed in a special debug section of the program file to allow the debugger to display the values of the variables.
where is the stored pointer type stored?
These non-types are also static (except for the limited dynamic type information associated with polymorphic class types, but not pointer types). The compiler knows this 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 (that is, if it is a class type with at least one virtual function), then there will be some static data to describe the type, stored in an unspecified location that you cannot directly access. There will be enough data to support calls to virtual functions (usually a table of pointers to final overrides) and RTTI (specification of the inheritance structure to use dynamic_cast
and the structure type_info
accessible via typeid
).
Otherwise, all type information is static.
Is [the compiled program] on the stack or heap, or is it just another piece of memory?
On a typical computer, it resides in static memory (code or text section) loaded when the program starts. On embedded systems, it may instead be located more permanently in persistent memory.
source to share
since references do not use additional memory, no further memory is allocated
How the references are implemented is not specified in the C ++ standard, but most compilers will implement them in the same way as pointers, so there will probably be 4 more bytes (on your system) for r
....
where the names p and r are stored
here is the type of the stored pointer?
Where type is stored [
r
]
They exist inside the compiler itself when you run it, and possibly in some debug symbol information placed in the generated objects / libraries / program to aid in interactive debugging if you use eg. GCC g++ -g
, but they are not saved or accessed through normal C ++ program statements.
I figured out that the compiled program is also somewhere in memory to execute it. Is it on the stack or heap, or is it just another piece of memory?
A compiled program is a collection of binary data codes and operation codes (numbers) of machine code that the operating system knows how to load and ask the CPU to interpret and execute. This data for this is usually not on the stack or heap, but is a mixture of "uninitialized data", "initialized data" and "code" segments / areas that the operating system orders.
source to share