Can Q_GLOBAL_STATIC replace KStaticDelete ?
thiago at kde.org
Tue Jan 9 21:18:47 GMT 2007
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?).
>>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
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel