[Qt-interest] Maintaining strong references (shared pointer) to Qt objects

Andreas Pakulat apaku at gmx.de
Sat Jul 24 10:55:29 CEST 2010


On 24.07.10 08:51:56, Anatoli Steinmark wrote:
> -------- Original-Nachricht --------
> Datum: Sat, 24 Jul 2010 08:45:22 +0200
> Von: "Anatoli Steinmark" <derletztemohikaner at gmx.de>
> An: "Malyushytsky, Alex" <alex at wai.com>
> Betreff: Re: [Qt-interest] Maintaining strong references (shared pointer) to Qt	objects
> 
> Hi Alex,
> 
> > I don't understand a reason widget should not be deleted.
> > What is going to happen to it? Persist until application exits?
> 
> I'm writing a scripting language binding for Qt. This requires Qt objects to be exposed as objects of the scripting language. Thus the need to maintain a strong reference, since if a parent destroys a child, the reference in the script object becomes a dangling pointer.
> 
> Until the script object is collected (destroyed) by the script engine, the Qt object it exposes should not be deleted.

Thats not how (existing) script bindings work. You simply cannot do
this, what you can do though is getting notified when the wrapped Qt
object is being destroyed and then make sure that you throw a proper
exception when a user tries to access the script object. 

> > It does not mean you can't prevent widget to be deleted by parent.
> > For example you can subclass parent and keep the least of the widget you
> > don't want to be deleted.
> > Re-parenting them to NULL in the parent destructor should do it.
> 
> So I would need to subclass every Qt class I want to expose to script?
> 
> I see this is a solution, but if there is a way to avoid this mass-subclassing, I would prefer it.

Most script-language bindings are generated these days, so the number of
classes to generate is not that much of a problem. Of course there's
going to be cases where auto-generation fails or you'll have to tweak
it.

> I always read that Qt does reference counting everywhere, so if that's
> true there has to be a way to acquire and release references.

It does reference counting on data-classes like QString, QList, QMap
etc. But it never did and cannot do this for the widgets.

There is a SharedPointer class in Qt4.6 and later which might or might
not help (I'm not 100% sure I understand its semantics). Thiago once
blogged on the Qt blog about the various smart-pointer classes in Qt4.6
and later, maybe have a look at that.

> > If it still keeps the references to external objects in the widget,
> > release them when widget is deleted.
> > If you reference this widget in external code, notify such code that it is
> > going to be deleted.
> 
> Hm, that would be very counter-intuitive and surprising to programmers
> if the script object suddenly looses the Qt object it represents just
> because a parent is destroyed.
> 
> Or to put it another way: If there is a valid script object, it should
> have a valid reference to the Qt object it represents.

As I said before, thats not how existing script bindings for Qt work
(afaik).

Andreas

-- 
Beware of low-flying butterflies.



More information about the Qt-interest-old mailing list