|
Boost : |
From: Gregory Dai (gregory.dai_at_[hidden])
Date: 2007-05-10 14:05:01
On 5/9/07, Joaquín Mª López Muñoz <joaquin_at_[hidden]> wrote:
>
> Gregory Dai ha escrito:
>
> > On 5/9/07, Joaquín Mª López Muñoz <joaquin_at_[hidden]> wrote:
> >
> > > Hello Greg, I think there's a potential problem with your
> > > static_instantiation policy [...]
> > > You can solve this by combining a Meyers singleton with some static
> > > initialization forcing technique:
> > [...]
> > Isn't this kind of equivalent to the local_static_instantiation (the
> second
> > policy)? In general, we use local static storage to avoid static class
> > member construction, don't we?
>
> These policies work differently: local_static_instantiation creates the
> singleton the first time make() is called, be it in initialization time or
> after main() has begun; while static_instantiation guarantees that
> the creation always happens in initialization time.
>
> > In other words, shall we say that the static_instantiation
> (instantiation
> > policy) is there for illustration purpose only, not for applications in
> > production.
>
> I'd say there is an important use case for static_instantiation which
> local_static_instantiation does not cover: if no threads are launched
> before main() begins, which is an extremely common situation, then the
> automatic creation of the singleton in initialization time is naturally
> thread
> safe, and so singleton<...>::instance need not be mutex-protected
> even if in a multithreaded app..
>
> Joaquín M López Muñoz
> Telefónica, Investigación y Desarrollo
>
You've got the final word, Master of Rome!
Cheers,
Greg
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk