K_GLOBAL_STATIC

[Maximilian Kossick]

On 8/26/08, Ian Monroe <ian at monroe.nu> wrote:
> On Tue, Aug 26, 2008 at 7:54 AM, Maximilian Kossick
> <maximilian.kossick at googlemail.com> wrote:
>> I'd have to look it up again this weekend, but as far as I remember
>> destruction of static objects the way we defined them earlier happens
>> at destruction of the application, and therefore is totally out of our
>> control too (just like K_GLOBAL_STATICs without that qPostRoutine). If
>> I remember this correctly, replacing K_GLOBAL_STATIC with our previous
>> approach for singletons won't gain us anything.
>
> The previous (perhaps not universally used) approach isn't static
> objects, but just static pointers. Deconstruction could happen
> precisely where we put a 'delete' statement or based on a QObject
> parent.

The only way to create singletons that I remember from Amarok1 was this:

static FooBar instance;
return &instance;

Is that what you mean?

>> The whole approach is flawed anyway, what we really need is state
>> management for amarok, i.e. there would be a single class that would
>> control the creation of essential services on startup, and control the
>> order of destruction on shutdown. This was actually proposed by Mirko
>> during last year's akademy, but I never got around to writing that
>> code (I haven't even finished designing it, although I still have a
>> couple of attempts lying around on my laptop back home). You could do
>> a couple of interesting things with that kind of state management
>> (e.g. threaded startup, easy power management), so if somebody wants
>> to implement that for 2.1 ...
>
> Which sounds like a more formal way of how we did things in Amarok
> previously, at least in the MMM-era.
>
> It sounds like a neat idea, especially as a way to document all the
> various systems and their dependencies for old and new Amarok devs.

Yes, I forgot about the dependencies. But what's the MMM-era? Markey,
mueslie and mxcl?

-Max