On quinta-feira, 24 de maio de 2012 11.46.05, Alberto Mardegan wrote: > On 05/23/2012 02:43 PM, Thiago Macieira wrote: > > 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. > > Nice! However, a very hard thing to do as an aftertought. IMHO, it would > be easier if the reference count was built in QObject itself, and > QSharedPointer<QObject> would just play with that reference count. > Then you would also be able to make the "delete" operator work > consistently with reference-counted QObjects, by overriding it and make > it just decrement the count (and delete the object if the count is 0).
It's not very hard to do that. I've done it in the past. By doing that, we
make it so that each QObject parent tracks its children as if it had a
QSharedPointer reference to it.
The problem are the side-effects caused by a child surviving a parent deletion.
> However, I didn't think it thoroughly through, and I'm sure there would
> be issues with this approach as well. But indeed I'm convinced that
> using QSharedPointer and the unmodified really-deleting delete operator
> in the same code is also a recipe for disaster.
That's not allowed. If you use QSharedPointer, then QSharedPointer *WILL*
delete the object by calling the custom deleter.
That means you have a workaround by adding a custom deleter that doesn't
delete. But that's your problem.
> > 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?
>
> Unless the code calling object->setParent(0) still has a reference to
> the object, yes.
That makes sense. You can imagine that the refcount was 2 when you did object-
>setParent(0), but that last reference that remained was in another thread
that has just dropped it. That would cause it to be deleted before your next
line in the current thread -- or, at least, for deleteLater() to be called.
--
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
