[boost] Re: Singleton

From: Dave Handley (dave.handley_at_[hidden])
Date: 2005-01-06 06:49:12

David A. Greene wrote:

> 
> Dave Handley wrote:
> 
> > 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.
> 
> Definitely.  I've been wanting this for a long time.  I haven't had
> a chance to look at it yet, but from your description, your composite
> and visitor code is a good starting point.  I'd love to help out
> with this effort.
> 

I can provide a starting place on both the Visitor and Composite, but
don't really have anything in the Singleton area that is up to
scratch.  Does anyone have a starting point for that - if so I suggest
putting them all in a namespace like patterns and getting everything
posted into the Yahoo group for some general comments.  If there is
interest, I could then set up a SourceForge project to run things
from.

I have to say that my code is flawed at present though:

1) My Visitor only supports acyclic visiting, but should support both
cyclic and acyclic.  I also want to set it up for const and non-const
visiting (something else that the Loki visitor is weak at).

2) My Composite has a few major flaws.  The first is that I need to
make the iterator fully STL compliant - but that is relatively easy. 
The second is more serious and concerns destruction policy.  At
present, calling the destructor on composite objects causes dangling
pointers.  I did this because of a really subtle issue implementing
the Composite in C++ which I will explain below, but I think
destruction needs to be something handled by a policy class - then
calling delete could optionally remove from the tree or not according
to the policy.

The flaw concerns the state of objects during destruction.  It is
quite common (in my experience) to use what I will term "Quick
Pointers" in a complex composite structure - for example in a CAD
system.  A Quick Pointer is basically a cache of a pointer to a child.
 For a quick pointer to be safely handled it must be set up and
deleted during the add_child/remove_child functions.  It also usually
needs to know the dynamic type of the tree members.  When you get to
destruction of the base class, the dynamic type of the node is no
longer known, so the wrong add_child and remove_child functions (which
must be virtual) get called - breaking tree invariants.  To get over
this you can make the base destructor protected, and force all
destruction through a base destroy function which is what I have done.
 But, if you aren't using these quick pointers, then there is no point
in this, and it is more intuitive to allow a call to the delete
operator to dismantle the tree appropriately - hence why I want to
make this into a policy.

Dave