On Tuesday 08 April 2003 07:46 am, Anders Johansson wrote:
On Tuesday 08 April 2003 12:45, Steven T. Hatton wrote:
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.
Discounting macro assemblers, there is a one-to-one correspondence between assembly instructions and binary instructions. The former is just a human readable version of the latter.
I don't recall the details of the lecture, but I do recall that in the example he used, there was not a one-to-one correspondence between assembly code, and the compiled binary executable.
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.
As far as I know, there are only two times when there is executable code on the stack.
I looked over the examples in Sebesta's book, and I will agree that I guessed wrong. I'm not srue what Mathematica and Lisp do, but these are birds of a different feather, AFAIK.
One is when you've been cracked. and the cracker uses a buffer overflow to insert the code, and the other is something called trampolines. which you can read about here
Thanks, I'll skip that for now. I'm already confused enought. :-)
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
The variable button1 is destroyed when the constructor exits. The object it refers to is not.
Normally in QT, you use the variables like button1 to set other variables, using methods like setMainWidget(). Those methods assign the objects to internal variables in the containers, so when the temporary variable button1 dies (when the constructor exits), they're not forgotten.
I should have stated that better. What I meant to say was: class MyClass { public: MyClass::MyClass(); ~MyClass() private: SomeClass mySomeClass; int myInt; }; MyClass::MyClass() { this->mySomeClass = someKindOfMagicToInstantiate(SomeClass); } It seems that I could pass an object of type SomeClass, and use that to initialize mySomeClass in the constructor. But that is a bit different.
Anders
STH