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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
