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

Anatoli Steinmark derletztemohikaner at gmx.de
Sat Jul 24 08:51:56 CEST 2010


-------- 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.


> 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.

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.

> Memory should not be a concern - correctly designed widget should not
> require more memory than required for visualizing the data.
> So if you need to have the same widget in 2 different places, you
> instantiate 2 objects.

Memory is not a concern. :)

> 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.


Regards,
Anatoli
-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail



More information about the Qt-interest-old mailing list