[boost] Re: Singleton

From: Dave Handley (dave_at_[hidden])
Date: 2005-01-05 14:02:44

> Does it make any sense to use a template allocator parameter, like the
> standard container types, to control creation and destruction of my
> instance, or are new and delete sufficient?

Singleton creation is an interesting issue - Loki provides a number of 
different creation policies, including creating using new, malloc, or 
creating statically.  Implementing them with a policy template.

> Is there any other functionality that should be added?  Specifically,
> is it sufficient to enforce that singletons are created in a specific
> order before main and destroyed in the reverse order after main (using
> dependency instances), or should I provide some way to support
> alternate lifetimes (ex: create on first reference to instance)?

Ordering of Singletons is, in my opinion, one of the most important issues 
with Singletons.  It is almost certainly insufficient in most applications 
to create in a specific order, and delete in reverse order.  One reason for 
this is start-up performance - you don't want every Singleton to have to 
create at startup (necessarily).  Another reason can be memory efficiency. 
Loki again provides a number of policies including a Phoenix Singleton and a 
Longevity managed singleton.  I personally tend to use Longevity managed 
singletons linked to the at_exit function.  Nevertheless, there are some 
additional things that I would like to see - for example, a phoenix 
singleton that could be created and destroyed more than once during a 
program run could be useful - either explicitly or even if not used for a 
while.  Also, allowing thread-safety as an option is also crucial.

> Is there any interest in adding this library to Boost?

I would love to see a robust implementation of a Singleton in Boost. 
Whenever I start a software project, almost without exception I tend to add 
both Boost and Loki to the project - it would be great if I could add only 
Boost.  I have to say however, that a more general library which implemented 
a variety of design patterns (like Loki) would be even better.  For example:

1)    Singleton
2)    Visitor - like Loki implementing both a conventional cyclic visitor, 
and an acyclic visitor.
3)    Composite
4)    Abstract Factory
5)    etc. etc.

I've written my own templatised composite (available on codeproject.com), 
implementing a number of different iteration strategies (deep iteration, 
shallow iteration, typed iteration, etc.) and would be more than willing to 
throw that into the melting pot if there was some interest in putting 
together a library of design patterns for Boost.  I've also written an 
acyclic visitor, like Loki but with a key change in the way that a failed 
visit is handled - in Loki if the visitor cannot visit a particular type of 
node, the default action is handled by a template in the base class of the 
visitable hierarchy.  This in my view is flawed, and the default action 
should actually be handled by the visitor if required - this keeps the 
concept of action and data separated in accordance with the original visitor 
design pattern.  This would probably need some work if it was to go into any 
attempt at a design patterns library.

Dave Handley