KAutoPointer: a new autoptr class for QPointer

[Thiago Macieira]

Ingo Klöcker wrote:
>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.

You're right. It would be better if this were the case.

However, imagine the case that you're editing data on a removable media. 
When you log out and remove this media, will the unsaved data be shown in 
another computer?

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

It doesn't. But I never said that QScopedPointer was the solution. I was 
pointing to the fact that Qt is adding classes like this and responding to 
David's point that this should be in Qt.

(in the thread starter: "Ideally this class would be provided by Qt, ...")

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

Remember that BIC here means also data compatibility and the stability of 
template expansion names. If you put boost::whatever in the API, then the 
name has to remain the very same for all users until KDE 5.

This, for example, changing public typedefs, changing of default template 
parameters in public classes, as well as changing data layout according to 
the compiler version.

I was trying to add a neat trick to QSharedPointer when I realised that my 
#ifdef for working around a gcc 4.2 bug would mean code recompiled with 
gcc 4.3 would changing the layout of data structures. I'm saying this 
because I know boost has a lot of workarounds for compilers, but unlike Qt 
they do like to use the latest new features. C++0x variadic templates can 
be a problem, for example, for the template expansion names.

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

I don't recall of any important breakage in Qt 4. We're very careful about 
that.

The only case I remember is QList gaining operator<< for QList, which 
meant that QVariantList << QVariantList now adds a list instead of adding 
a new QVariant containing a list.

This was not an intentional break, of course. In hindsight, we shouldn't 
have added the operator. Now there's nothing we can do.

In any case, this doesn't break binary compatibility.

There's a strong push for improved use of RAII in Qt, especially due to 
memory pressure on Symbian. I wouldn't be surprised if QObject becomes 
reference-counted in Qt 5.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090710/b9bf7618/attachment.sig>