On Tuesday 08 April 2003 05:13 am, Derek Fountain wrote:
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)
I may have missed more than you, and I've read it all! ;-)
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.
This is an interesting topic, which I hope not to go to deep into presently. What you said about assembly code is the way they taught it to me in my lower level courses. But, IIRC, one of my professors (the Italian guy who always held his coke as if it were a cocktail glass, and his chalk as if it were a cigarette) told us that RISC compilers will likely forego the assembly language step and directly produce binary instructions. The part that I'm not completely sure of is the role of glibc, and etc. For the sake of the original discussion, however, none of this matters. I'm not ready to go marching into this field quite yet.
At *compile time* the compiler will look at your class definition and say "that requires <n> bytes to store one object".
I have some uncertainty here. What you say makes sense, and I really believe this is what happens. However, what about objects such as strings? The compiler cannot know a priori what data will be stored in a string. This suggest to me the data of a string is not 'part' of the object. It is data pointed to by a member of the 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!
Again, my recollection of how the stack works is a bit hazy. What you say makes sense for objects on the heap, but at some point, the instructions need to be placed in the CPU. Either the image of a function invocation goes on the stack as a whole, or it consists of an entry address into the shared program image, and a return address to be loaded in the instruction pointer register when the function completes. Typically we wouldn't have hundreds of images of a function on the stack. Such a situation would only occur in some kind of recursive invocation where a function calls itself and therefore causes another instance of itself to be loaded on the stack. [I'm gonna back off form these implementation details for now.]
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.
Take a look at the code I posted in my previous message. That isn't what seems to be happening.
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" );
There's something I'm not getting here. button1 is a variable being assigned in the constructor. It is not destroyed when the constructor returns. Why should QButton button1 = someKindOfMagicToMakeAButton(); be destroyed upon returning from the constructor?
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)
QT seems very powerful, and well designed. I didn't realize how much C++ I didn't know when I started. May people wouldn't spend as much time trying to get at what's actually going on 'under the hood'. Some of this may never help me write code. I suspect, however, many of the people who simply pick up QT and start using the designer will reach a point where everything falls appart, and they don't know what to do to fix it. STH