KAutoPointer: a new autoptr class for QPointer

[Ingo Klöcker]

On Friday 10 July 2009, Thiago Macieira wrote:
> 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?

Unsaved data would probably be saved in the applications 
~/.kde/share/apps folder and thus wouldn't be shown in another computer. 
This might be a problem if one forgets to save the presentation before 
shutting down the computer before rushing to the airport to fly to the 
GCDS. So it might help to ask the user nevertheless and only continue 
with the logout after a decent timeout.


> >> >> 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,
> ...")

Ah, okay. I do agree that adding a shared pointer class (like 
KAutoPointer) playing nicely with QPointer does make sense.


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

With respect to boost a possible solution would be to stay with a 
specific version until the next major release. In fact, we (MMS) very 
rarely update the version of boost we are using. But we regularly update 
Qt because we want to use all those cool new features you keep adding to 
Qt. :-)


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

I was referring to the changes in the major releases. The transition 
from Qt 3 to Qt 4 is still causing a lot of pain and even makes people 
consider switching to other languages (with the intention to avoid such 
pain in the future).


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

Yeah, I remember. This change caused quite a few hard to find bugs. But 
that's not what I meant.


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

I think this would be a great improvement, but I suppose it would also 
require changing all QObject* API to QObject(&) API because otherwise 
the change would be rather point(er)less. I foresee great pain. :/


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/dc8724b9/attachment.sig>