Michael Pyne wrote: > On Thursday, February 10, 2011 16:35:20 Stephen Kelly wrote: >> Thiago Macieira wrote: >> > On Thursday, 10 de February de 2011 21:08:05 Stephen Kelly wrote: >> >> Thiago Macieira wrote: >> >> > It should have been in a qglobalstatic_p.h. We might even do that -- >> >> > and intentionally break applications that are abusing the API. >> >> >> >> A quick grep says that would break akonadi, grantlee, qca, phonon, qxt >> >> and a couple of places in KDE that use it already (presumably they >> >> don't need the features of K_GLOBAL_STATIC that you mentioned). If you >> >> (re)move it, we'd all just end up copying the macro into our own >> >> codebases, so that wouldn't achieve much. >> > >> > Phonon should have a copy of K_GLOBAL_STATIC. >> >> I noticed K_GLOBAL_STATIC uses QBasicAtomicPointer, which doesn't seem to >> be public API. Is that going away too? That would break K_GLOBAL_STATIC. > > Although you raise a good point, their docs are quite clear that the API > is not public, so pointing out *other* uses of non-public APIs doesn't > really help the argument, as Nokia is still within their rights to move > non-public API to non-installed headers.
What I was getting at was really just that if the recommendation is to use K_GLOBAL_STATIC, but then QBasicAtomicPointer gets moved to some _p.h file, that is screwed too. Then using K_GLOBAL_STATIC is not a good recommendation. The recommendation should be to use something that doesn't use Qt internals. FWIW I'm totally in favor of giving Q_GLOBAL_STATIC whatever features it doesn't have that make K_GLOBAL_STATIC the current better choice, possibly breaking existing users of Q_GLOBAL_STATIC in the process if it means making it public API. > > I say this as someone who uses QAtomicInt assuming a mode of operation > that is not explicitly documented (i.e. it is safe to initialize its > memory with 0 and avoid running the ctor). If Nokia changes it I would > grumble, but it would by my problem, not theirs. > > It also wouldn't really break K_GLOBAL_STATIC, as the code could simply be > "freed" from Qt in the event that were to happen, or be reimplemented in a > different fashion (such as gcc intrinsics, I would imagine). Yes, but krandomapplication is supposed to run against kdelibs 4.6 which has the current implementation of K_GLOBAL_STATIC. If QBasicAtomicPointer is removed in Qt 4.8, krandomapplication 4.6 won't work if linked against Qt 4.8. That's the kind of breakage I mean. Regards, Steve.
