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
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
- All agents use the DatabaseFacade asynchronously.
These are the possible scenarios of initialization of DatabaseFacade
1. Make a call to DatabaseFacade::initialize() from main (or other wiring
code), thus making main aware about DatabaseFacade, i.e. introduce an
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 ;)
With best regards,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk