Mailinglist Archive: opensuse-programming (128 mails)

[Derek Fountain <derekfountain@xxxxxxxxxxx>]

> > 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.

I thought I'd stick my nose back into this thread. If I've missed too much to 
say anything useful which hasn't been said before, just ignore me. :o)

Yes, he means compiler. Remember, the purpose of a compiler is to put together 
a set of assembly language instructions, and make them into an executable 
which the OS can run.

At *compile time* the compiler will look at your class definition and say 
"that requires <n> bytes to store one object". It will also look at the 
class' methods and say "this is the code which that class definition needs 
available". It will therefore squirrel away one copy of all the method code. 
Your guess in the quote above is wrong. :o) The instructions which make up a 
function are stored once in the text segment. No need to make hundreds of 
copies of a bit of code just 'cos you've got hundreds of objects 
instantiated. They can share!

When the compiler finds a bit of code which instantiates an object, either on 
the stack:

 MyClass fred;

or on the heap:

 MyClass* fred = new MyClass;

it needs to generate some code to do it. Remember: the compiler isn't doing 
the actual instantiation; the compiler is generating the code which does it 
when the OS runs the resultant program. So the psuedo-code generated will be:

 allocate <n> bytes in the right place (i.e. on the stack or the heap)
 call constructor subroutine with that memory block as a parameter

When the OS runs the program, a call to the system's memory allocation routine 
(malloc or similar under Linux) will be made. That will be followed by a call 
to the place in the program text segment where the constructor code has been 
placed, basically saying "here's an empty block of memory big enough to hold 
the object - fill it in!".

> 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.

Not quite. The program which the compiler has generated, and which is running, 
instantiates the objects. The program may very well use kernel or glibc 
facilities to do this (because the compiler knows about those facilities and 
generated code to use them), but that doesn't mean it's the kernel doing the 
instantiation.

> 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.

You mean, if you say:

 MyClass fred;

then the constructor for MyClass is called? Yes. And the member variables will 
be set to 0s by default (see C++ spec), or anything that MyClass' 
constructor, or any of the parent class' constructors sets them to 
explicitly.

> By looking over the QT example code, the Trolls typically use pointers in
> such cases.

Yes, because QT is about widgets and widgets need to remain in place after the 
code which creates them has been and gone. (e.g. Can't have all those buttons 
which your toolbar created disappearing when the toolbar constructor is 
completed and exits, can you?) So Qt creates the buttons on the heap:

 QButton* button1 = new QButton( "Quit" );

and keeps the pointer (button1 in this case) around in the Toolbar class. When 
the toolbar is destroyed, the destructor will ensure all the objects the 
button pointers are pointing to are correctly destroyed.

If Qt did it on the stack:

 QButton button1("Quit");

when the toolbar constructor exits, the stack memory allocated for that button 
will be reclaimed and reused. That would be *bad*!

Qt, BTW, does all this pointer juggling for you: you create a toolbar and add 
buttons to it. When you destroy your toolbar, Qt handles the tidying up of 
all the buttons, etc. Gotta love Qt... :o)

-- 
"...our desktop is falling behind stability-wise and feature wise to KDE 
...when I went to Mexico in December to the facility where we launched gnome, 
they had all switched to KDE3." - Miguel de Icaza, March 2003