KAutoPointer: a new autoptr class for QPointer

[Frank Osterfeld]

On Thursday 23 July 2009 15:37:42 Lubos Lunak wrote:

> > It's not just quit, anything that deletes your widget causes the problem.
>
>  It does not cause the problem, it is the problem. If they are my widgets,
> I delete them, not some random anything.

Well, or your parent widget because it itself is deleted. Otherwise the code 
that wants to quit the application or replace e.g. the KPart in Konqueror has 
to make sure that slotDoSomething() and everything else giving the control to 
the event loop is left before the widget is deleted. I don't see a good 
pattern that does that and can be applied easily to the existing codebase.

> > > ParentWidget::slotDoSomething() should return control to the main loop
> > > and from there the exit and cleanup should really happen.
> >
> > Can you elaborate how that would look like in code? I.e. how
> > slotDoSomething() should handle the case that quit() was called or
> > konqueror wants to delete the widget in between?
>
>  There is no need for any special handling in slotDoSomething(), because it
> is not broken. The thing that needs fixing is whatever deletes the 'this'
> widget while it is still in use (which it is, since the control flow is in
> this->slotDoSomething()).

the "whatever that deletes this" doesn't know about slotDoSomething(). 
slotDoSomething() gives away the control in the moment it calls exec(). As of 
now, if slotDoSomething() calls QDialog::exec() or anything else processing 
events has to take care that everything is still in order after the event 
processing.

> > It's a "make sure the dialog is deleted, one way or another" pointer that
> > combines the ownership model of QObject with std::auto_ptr-like behavior.
> > It might be too much of a special case to justify another pointer class,
> > but then we need another solution.
>
>   Arguing that at least something random should delete the stuff is like
> thinking that garbage collection magically fixes all resource problems. The
> solution is to fix the bug or at least show that it can't be fixed and a
> workaround is needed. Not even the latter has happened, you just said "hey,
> something deleted my widget behind my back, I propose this class as a
> workaround".

I just want to get rid of those crashes, in a fault-proof way. I still don't 
see a pattern that a) can be applied to existing code with realistic effort b) 
is easy enough to grasp c) doesn't require major Qt or kdelibs refactoring. 
That doesn't mean that there is no solution, but before it's there, I still 
think Q/KAutoPointer is the most practical approach.

Frank