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