On Monday 07 April 2003 11:09 am, Jerry Feldman wrote:
On Mon, 7 Apr 2003 00:08:54 -0500
"Steven T. Hatton"
wrote: Yes, my statement doesn't really make a lot of sense now that I think about it. What matters is not how the class is defined, but rather how objects of that type are instantiated.
A class definition is saved in the compiler's memory space during compilation. Non-inline functions certainly do take up space in your program's text segment (usually). class static variables are generally allocated in the program's data segment. But the rest of the class is simply a template for the compiler to use when the class is instatiated.
Did you really mean 'compiler' here? I'm way out in unfamiliar territory here, but I would guess it is the OS kernel which uses this 'template' for instantiation. I'm trying to recall if the actual instructions of a function get placed on the stack. My guess is, instructions *do* get placed on the stack along with local variables.
As Anders mentioned, there are a lot of implementaiton details. How the compiler actually allocates the storage for the class once instatiated is up to the compiler. In general, automatic variables (eg. those vatiables that exist inside of a function) are allocated on the stack.
I can tell I need to really hit the books if I want to understand this stuff. As I recall from years ago, the compiler does have a lot to do with the runtime behavior of the program. Nonetheless, the compiler has already done its job, and the kernel is the component actually doing the instantiation of classes as objects, and the memory allocation. I'm sure you know this, and are simply using a manner of speaking which implies as much. I'm just pointing out that there is yet more involved than the compiler.
In this case. mc is allocated as a local variable. The compiler may allocate some components of the class on the heap, or it may mmap them. But, they will behave as if they were local variables. When you return from doThis(), the storage for mc will be returned back to the system. void doThis() { MyClass *mc = new MyClass; mc->myMethod(); } In this case, the storage for mc will be allocated in a persistent mannter, classically on the heap, but the compiler may mmap it. When you return from doThis, the variable mc (eg. the pointer) goes out of scope, and you have a memory leak.
Yes. This is the part that really matters to a novice like me.
One of the important things to remember, is that variables within the class must be explicitly initialized, either from within the constructors (by default or explicitly), or explicitly by you.
example: string foo("a string"); // the string, foo is explicitly initialized // by you through the constuctor. string *foo = new string("a string"); // same as above. string foo; // The default initialization will create the default // empty string for the string class.
When you design a class, you should make sure that all the variables in the class are initialized when the constructor is called. Otherwise, you could have some difficulties later.
However, from my observations, if I simply declare a variable of derived type, and never explicitly initialize that variable, the constructor of that class *is* invoked, and the member variables of that object *are* initialized. I'm trying to put together an example complex enough to demonstrate some of the issues which had me confused, and yet simple enough to present on this list. Part of that example involves the chaining of constructors. That is, the instantiation of objects within the constructor. This happens when I am writing GUI code. I want the main window to have 'children' which in turn may have children. I found I could do this if the children were referenced by pointers from the parent object, but not if the children were members of the parent objects. By looking over the QT example code, the Trolls typically use pointers in such cases. STH