Re: [boost] Is there any interest in static constructors?

Subject: Re: [boost] Is there any interest in static constructors?
From: Alexander Stoyan (alexander.stoyan_at_[hidden])
Date: 2013-02-05 11:34:40

Okay, I believe I need to provide a really good example that can show the
need of static construction with no preliminary calls to initialization
functions.

The example if part of my work project:
 - I have two layers: presentation and model.
 - Each layer work in its own thread because presentation must remain
responsive whatever happens in model.
 - Model itself is an abstract layer, the actual logic implementation is
implemented in specific agents, so the model is not aware of the agents.
 - Agents are asynchronous tasks.
 - I have DatabaseFacade utility class, internal data of which require some
preliminary initialization, like setting initial values, creating locks,
filling hash maps, but not actual connection because it's a proxy to real
database object.
 - All agents use the DatabaseFacade asynchronously.

These are the possible scenarios of initialization of DatabaseFacade
internal data:
 1. Make a call to DatabaseFacade::initialize() from main (or other wiring
code), thus making main aware about DatabaseFacade, i.e. introduce an
unnecessary dependency.
 2. Call DatabaseFacade::initialize() from model construction, again
introducing an unnecessary dependency, because the abstract model doesn't
care about some specific needs of some agents.
 3. Call DatabaseFacade::initialize() during specific agent construction.
But another agent can be inside a call to DatabaseFacade::initialize(). So,
I'd need to wrap it in critical section. But the critical section itself
has to be initialized before agents start. Should I introduce dependency on
this specific critical section to the abstract model? Nop. Should I wrap
DatabaseFacade::initialize() inside in a static critical section thus
making assumptions about clients of the function? Nop again.

And by introducing public method DatabaseFacade::initialize() I will open
a possibility for double initialization. Of course I can insert checks, but
the checks can reveal problems at run-time only. So  it's more correct to
allow a class to initialize its internal data itself on its own discretion,
thus writing robust API that cannot be misused: "Anything that can go wrong
will go wrong" - Murphy's Law ;)

Thank you.

______________________________
With best regards,
        Alexander Stoyan