Re: Stack

Great informative reply.

I guess I sort of confused the stack memory allocation with the allocation of variables in the program. For some reason I read the quote as saying that when the program is run, all the stack variables in the program will be allocated and initialized. That's obviously not what it meant. I guess it's the act of reserving memory for the stack and the book keeping like initializing the stack pointers, frame pointers etc...

I am not sure as to what happens exactly happens, when say new is used. The object created, is created on the heap, but maybe it is accessed through a pointer to it's memory address, stored somewhere locally by the operating system. Just check this out, not sure how it's implemented in C++.

Well, when you use "new", you get back the address of the object created on the heap. Generally you store that address in a local pointer variable, which is stored on the stack. I dunno if this was your doubt.

I suppose the big difference between the stack memory and the heap (free store) is that allocation on the stack takes constant time (its just a pointer increment and constructing) whereas allocation on the heap is not necessarily constant. It needs to find a large enough space to be able to hold the object. I've read that the heap is implemented as a linked list sort of data structure. Dyou know anything about this?

There are three main types of object files.

Great info again. I didn't realize there were different types of object files. I just thought after you compile, you get a .obj file and after you link you can a .exe. Could you elaborate on #3 a bit? I didn't understand what the dynamic linker was.

I sometimes think that to be a true great when it comes to C/C++, one has to have some compiler design experience, then only you can truly know all the small nuances associated with this language.

I feel like it's more curiousity than anything else. As in, I have this concept of a stack in my mind, but how exactly does it all come together? Also, how does the system find a large enough free space on the heap for allocation. This is all good to know info and I find it interesting, but you don't particularly need to know it to be productive with C++. But as you say, to be "great", yeah, that's a different story. Knowing the guts of how the system works is critical.

I think having a good background in OS would help a lot especially when it comes to memory issues cause it's the OS setting up everything. I agree with you regarding knowing what the compiler is doing. It might be pretty worthwhile to play around with the CFront compiler which compiles C++ code to C. Stan Lippman uses this technique in his book "The C++ Object Model".