Can Q_GLOBAL_STATIC replace KStaticDelete ?
thiago at kde.org
Thu Jan 18 11:13:29 GMT 2007
Simon Hausmann wrote:
>I just spoke with Brad and the bad news is: Do not use Q_GLOBAL_STATIC.
> It is going to change in the future. Also do /not/ use the
> q_atomic_with_underscore functions. They are going to change as well.
> Q(Basic)AtomicPointer is good to use though. (reasonably safe ;-)
We still need Q_GLOBAL_STATIC. Like I said in the original email in the
other thread, there is simply NO way of accomplishing a thread-safe
static object creation without it, global or not, unless we start
requiring that KApplication or KInstance be already created. And we will
need that for any and all singletons.
We cannot rely on a constructor function to create a global QMutex for us.
We cannot rely on a constructor function at all, since any of our
libraries may have been loaded as a result of plugin loading -- which may
skip constructors in some systems.
We cannot also rely on the C++ compiler having guards against reentrancy
in static objects. I remember reading the C++ spec: it leaves
specifically undefined the behaviour of reentrancy. This includes
thread-safety. (g++ 4.x is fine, though)
In all, we need Q_GLOBAL_STATIC or we'll be forced to implement it with
pthread or QBasicAtomicPointer for KDE. Any chance we can get it for Qt
I'd rather not copy qglobal.h, do a s/Q/K/g and change
q_atomic_test_and_set_ptr for the QBasicAtomicPointer that simply calls
One other thing: Q(Basic)Atomic(Pointer) uses the
q_atomic_with_underscores functions inlinedly.
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