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.
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. 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 http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html Generally speaking, the areas of memory used to store data don't store executable code. On some hardware platforms that can be enforced. On the sparc, for example, you can tag a memory area as 'data', and it will trigger an error if the program then tries to go there in its execution.
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. Anders