Can Q_GLOBAL_STATIC replace KStaticDelete ?

[Thiago Macieira]

Matthias Kretz wrote:
>On Tuesday 09 January 2007 20:31, Thiago Macieira wrote:
>> Yes: by defining the order in which they are constructed.
>
>So if I were using Q_GLOBAL_STATIC instead of KStaticDeleter my
>Phonon::Factory would be destructed before Qt's allObjects is gone. One
>problem fixed (though without a guarantee that it works on other
> platforms and keeps working like this?).

I said:
>>This result may be non-portable.

I don't know what the C++ spec requires. It seems reasonable that each 
DSO's destructors be run in the reverse order in which they were 
constructed. This would guarantee that any dependency be constructed 
before the dependee and destroyed after.

It also seems reasonable to expect that per-function static (which is what 
Q_GLOBAL_STATIC actually is) be destroyed in the order they are created 
(using atexit(3)).

But I don't know what the C++ spec requirements are, aside from the 
before/after main() requirement.

In addition, Q_GLOBAL_STATIC and KStaticDeleter exist because we know 
global constructors and destructors are sometimes, in some platforms not 
run at all. That completely breaks the C++ spec, but it exists.

>But it still doesn't help with dirty KConfig objects that need a
> KInstance on destruction.

I can see only two possible solutions:
1) make it not depend on KInstance on destruction
or 2) make KInstance notify of its destruction, like qAddPostRoutine

#1 does not mean "don't depend on KInstance", but "make sure destruction 
doesn't need it". When KInstance goes away, it could flush all KConfig. 
(Though I doubt that's a good idea).

-- 
  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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070109/7b64f166/attachment.sig>