Daniel Albuschat wrote:
that Qt docs and Qt examples, etc. seem to emphasize on heap-allocation
in situations where it absolutely is not needed (nor desireable)
Just an interesting semi-counter-example: Just about every Qt example
program I've seen starts by allocating a widget on the stack in main().
A pedantic side note regarding semantics: Class member variables
declared as non-pointers are often referred to as "stack allocated" even
though they are really allocated wherever their owning class is
allocated. I will follow this semi-misused phraseology in the paragraphs
My experience has been that while allocating non-pointer QObjects on the
stack works, it is often better to use the heap, simply so you can
control *when* the allocation (and subsequent constructor calls) happen.
It may be faster to perform the allocation on the stack (pointer
increment instead of memory management), but bare in mind that
allocating a C++ object implies calling its constructor too, which
always takes some time, whether on the heap or stack.
For example, if I create a QWidget-derived MyWidget class, which has
instances of FooWidget, BarWidget, and BizWidget as member variables, I
don't necessarily want my FooWidget, BarWidget, and BizWidget objects to
be instantiated every time MyWidget is instantiated, because I don't
want MyWidget to take that long to instantiate. I therefore choose to
defer instantiation until they are needed, thus improving the
instantiation time of MyWidget. If MyWidget is instantiated at
application startup time, then the application will start more quickly,
which is a Good Thing.
There's nothing worse than waiting for a GUI application to startup
simply because the author chose to naively instantiate every single
widget application-wide, even if they are not used during the life of
the application (i.e., dialogs). This is what can happen if you choose
to use non-pointer member variable QObject instances, because your code
forces the instantiation of each member to happen at the time the
"parent" object is instantiated.
I also agree with the previous poster that dynamic memory allocation is
very rarely the source of performance bottlenecks in semi-modern desktop
To unsubscribe - send a mail to [email protected] with
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/