KAutoPointer: a new autoptr class for QPointer

[Thiago Macieira]

Ingo Klöcker wrote:
>On Friday 10 July 2009, Thiago Macieira wrote:
>> 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.

Sounds like a good solution to me, even despite a small surprise effect 
present (sometimes it restores, sometimes it doesn't, for users that 
didn't realise that switching computers is the reason it doesn't).

Anyways, we have the framework for that, in KSaveFile.

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

Damn those Trolls for adding cool features :-)

Rest assured I've asked them to stop doing performance improvements for 
4.6. Let's leave some for 4.7.

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

Ah, ok.

Yeah, Qt 4 was far too big a change. Which is why there's no Qt 5 in 
sight. (We're more likely to hit 4.10 before that) And anyone I hear 
thinking[*] of Qt 5, thinks of it as mostly source-compatible anyway.

[*] yeah, I can hear thoughts

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

Yes, that's the big problem right now. And that's also the reason why 
QSharedPointer doesn't fit for the reasons David started this thread.

QSharedPointer manages the pointer's lifetime. You can't delete the object 
while there's a reference. And QObjects can be deleted. That's a major 
source of pain for us, especially when dealing with cross-thread signal 
and event delivery. We have some very, very weird corner cases like 
QObject being deleted in one thread, while a second thread has a QPointer 
to the object being deleted as well. And don't get me started on the 
problems that moveToThread introduces.

Most of those problems would be solved by having QObject not be deleted at 
arbitrary times. Unfortunately, reference counting everywhere introduces 
cyclic reference counting...

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