KAutoPointer: a new autoptr class for QPointer

[Ingo Klöcker]

On Friday 10 July 2009, Thiago Macieira wrote:
> Ingo Klöcker wrote:
> >Obviously, this situation arises if the user logs out while there is
> >still some application showing a modal dialog. IMHO the user should
> > not be obligated to close all modal dialogs if he wants to log out.
>
> Yes, he should. If an application has unsaved data, it has to show a
> dialog asking confirmation. And if another modal dialog is in the
> front, he has to dismiss that dialog.

That's just a hack to work around problems applications have with 
session management. If you quit KMail while you are composing a message, 
then, on the next start, KMail will re-open the composer and you can 
continue composing the message as if you'd never quit KMail. And I 
really love Firefox's ability to restore a half-filled form on the next 
start of the session. I use it a lot in combination with Bugzilla.

If an application loses unsaved data (or asks annoying questions) 
because the user logs out without saving this data then I call this a 
bug in the application. There might be applications where it is not 
feasible to save unsaved data, but I cannot think of any atm. Since 
exactly the same mechanisms can be used to prevent data from being lost 
when the application crashes (kdevelop comes to mind) it should be 
standard behavior.


> >> Which is completely unnecessary and we have numbers of leaks
> >> because of this, as soon as the control flow becomes even slightly
> >> more complicated. I would of course rather see this with the
> >> object simply allocated on the stack, but using a scoped pointer
> >> here is still much better. The same with classes, which should
> >> rather use scoped pointers for objects they own rather than
> >> listing delete calls in the dtor.
> >
> >I wholeheartedly agree with this. Unfortunately, there appears to be
> >quite some aversion against using boost's pointer template classes
> > (a trivial compile time dependency) in KDE, so using scoped
> > pointers will not happen until Qt 4.6. I'd really love to know what
> > technical reasons this aversion is based on.
>
> Which of the boost pointer classes integrates with QPointer
> clear-when- deleted mechanism?

Please excuse me playing the ball back to you, but in which way does 
QScopedPointer integrate with QPointer clear-when-deleted mechanism? In 
which way is QScopedPointer different from boost::scoped_ptr?


> By the way, does boost have binary compatibility guarantees in those
> classes?

Here you might have a point. But it's really a moot point since I don't 
see why anybody would want to make BIC changes to such simple classes. 
Of course, my believe is no replacement for a guarantee.

BTW, Qt has broken source compatibility even for the rather trivial 
container classes three times already making it impossible (much to my 
regret) to argue in favor of Qt's containers in discussions about using 
the STL containers instead.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090710/0f6222a3/attachment.sig>