All:
> W00t should have a backlog which covers the conversation,
> if it was done on our public channels :-)
If only Pierre de Fermat had had that feature!
Atlant
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf
Of [email protected]
Sent: Wednesday, May 23, 2012 09:52
To: [email protected]; [email protected]
Subject: Re: [Development] On QML, ownership, QObject-trees and QSharedPointer
W00t should have a backlog which covers the conversation, if it was done on our
public channels :-)
--
Sent from my Nokia N9On 5/23/12 13:44 ext Thiago Macieira wrote:
On quarta-feira, 23 de maio de 2012 14.16.12, Alberto Mardegan wrote:
> On 05/23/2012 01:25 PM, Rene Jensen wrote:
> > Question: How can we expose objects governed by QSharedPointer to QML
> > safely? I can guarantee the lifecycle beyond the life of my
> > QDeclarativeEngine.
>
> As neither of us knows exactly how QML handles QSharedPointer (my guess
> is that it simply doesn't; QSharedPointer is a template class which can
> be used with many other types than QObject, so I don't think that
> exposing it in QML is trivial), I would simply recommend you not to use it.
> I actually mentioned QSharedPointer in a recent blog post of mine [0],
> which you might find interesting especially if your use of
> QSharedPointer is suggested by your previous experience with other toolkits.
> If you really think that QSharedPointer is absolutely necessary in your
> case (I still doubt), then just expose its QObject data to QML, since you
> also claim that you can make sure its lifetime will survive the engine.
Just a tidbit...
I've long wanted to make QSharedPointer on QObject-derivatives participate in
the whole-tree ownership, somehow. I introduced QSharedPointer in 4.4 and I
did some work in 4.5 to make that work.
My original solution was to have a parent only deref its children's shared
pointer counter, deleting it only if it became zero. That means that if you
had a QSharedPointer to an object in the middle of the hierarchy, that object
would be orphaned instead of deleted when the parent died. The converse was
that when the last QSharedPointer reference to a QObject went away, the object
might survive if it still had a parent.
There were a few problems with that solution. I can remember now:
1) it didn't play very well with QWidgets after the Alien project. QWidgets
often reference the top-level window, which is the ultimate parent widget (the
one with no parents). Orphaning a QWidget from QWidget's destructor was a
recipe for disaster, since the original TLW data might have been gone already.
2) it didn't play very well with QObject siblings talking to each other during
destruction or, worse, deleting each other. This is a huge pain and source of
complexity during QObject infanticide.
3) what happens if you had a QSharedPointer<QObject> with a parent, dropped
the last QSharedPointer reference (it survives because of the parent) and
later orphaned that object via setParent(0)? Should it be deleted?
The worst of it all is that I remember having a discussion during 4.6 times
with someone on IRC and coming up with a brilliant and simple solution.
Something like "don't orphan, but keep a refcount on the entire tree". The
problem is that I didn't write it down, because I thought it was so simple and
evident that I'd be able to remember or work it out again.
I haven't been able to. Fermat would be proud.
Anyway, that reminds me I have some pending QSharedPointer work to do. I'll
get on with it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
Click
https://www.mailcontrol.com/sr/Bj8gU1boyQLTndxI!oX7UjaeDmea67kX7SqObTicsrBLI7iRALOOZRgXDSSm+ebxNAjdtRoTpmRPbv5+FCDqIw==
to report this email as spam.
This e-mail and the information, including any attachments, it contains are
intended to be a confidential communication only to the person or entity to
whom it is addressed and may contain information that is privileged. If the
reader of this message is not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error, please
immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
