Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

[Stephen Kelly]

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.