K_GLOBAL_STATIC

[Ian Monroe]

On Tue, Aug 26, 2008 at 5:52 AM, Seb Ruiz <ruiz at kde.org> wrote:
> Hi devs,
> Max, this one is specifically for you.
>
> During Akademy we discussed the use of the K_GLOBAL_STATIC macro
> throughout the Amarok codebase. We should all be aware of the previous
> heated discussions as to whether we should/should not be using this
> macro so extensively throughout our source.
>
> For what it's worth, the advantages of using this macro are:
> a) Awesome code style, which is what all of us crave and strive for to
> the utmost. No messing around with Class::instance()->method() calls
> b) We write 12 less characters
>
> This would be really cool if weren't punished with one fatal flaw of
> the macro, non deterministic destruction of K_GLOBAL_STATIC objects.
> This is a major problem because during an Amarok shutdown we need to
> guarantee the availability of static object instances for writing
> config settings and shutting down services etc. Now of course, there
> is a work around to this, which is to add and remove the object as a
> qPostRoutine where relevant. Having to do this has more repercussions,
> such as nullifying the cool code style (we need to add cryptic
> methods) and, more importantly, we need to remember to add this code.
> Without it, Amarok will have a much higher crashyness factor. Case in
> point, we are still having occasional random corruptions on shutdown.
>
> In summation, a few of us who discussed this at Akademy would like to
> propose moving away from the K_GLOBAL_STATIC entirely, and back to our
> trusted Class::instance() (or The::class() ) where we can reliably and
> deterministically define the order of desctruction. There has already
> been a volunteer to do the tedious dirty work.

As long as your going towards determinism, you should have the
The::class() only return a pointer - not create the class if it wasn't
already. Then you can precisely decide where you want the construction
of the class to happen.

At least, its something to think about. Maybe a case-by-case thing.

Ian