|
|
I don't agree with your assessment.
QT is designed to build truly component software. The management of
memory and connections is well done so that I don't have to be
concerned with walking a window list and deciding what to delete or
disconnect. When a parent dies, it's children die. What if the
child is a stack object? Well you could argue for a flag in QObject
that tells QT not to delete the object, but then you open a can of
worms. On desktop computers today, heap allocation is relatively
quick as compared to the user experience. On QTopia, I imagine that
extra work and care may be required to enhance speed. I.E. On the
Pocket PC platform, I wrote a smaller XML parser as opposed to using
MSHTML. It was 70% faster and made a huge difference in the user
experience. I put forward that this is an exception and not a rule.
What I have just written is just one short argument against what you
propose. There are others.
Regards,
Michael
On Aug 10, 2007, at 4:39 PM, Daniel Albuschat wrote:
2007/8/11, Andreas Pakulat <apaku@xxxxxx>:
On 10.08.07 23:24:18, Lars Knoesel wrote:
BTW: Do you have some links that explain how/why allocating on the
heap
is more expensive than on the stack? (I'd be interested seriously
as I
didn't delve that much into these things myself yet).
That's very simple to explain: Allocating on the stack costs
*nothing* but
incrementing the stack-pointer, while allocating on the heap costs
looking up for a
suitable place in the fragmented RAM, possibly rearranging and
remapping previously
allocated memory pages, etc.
Lars is right, IMHO, that 90% of the "new"s used in Qt are
unneccessary.
For example, the child-widgets of a dialog usually (virtually
*always*) have
the same lifetime as the parent widget, so it makes perfectly sense
to just
have them as normal (i.e. not pointer-) members in the class,
instead of having
a pointer as the member and calling new QBla(this) in the ctor, since
it's basically
*the same*, the object will have exactly the same lifetime.
The only true advantage kicks in when reparenting widgets, but I
rarely do that,
and a smartpointer-solution would work in that case, too.
Kind regards,
Daniel Albuschat
--
eat(this); // delicious suicide
--
To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx
with "unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/
--
To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/
|
|