K_GLOBAL_STATIC

Jeff Mitchell kde-dev at emailgoeshere.com
Tue Aug 26 14:21:15 CEST 2008


Seb Ruiz 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.

I wasn't at Akademy, but +1 from me.

--Jeff



More information about the Amarok-devel mailing list