----- Original Message ----- From: "Dave Handley" <dave@dah.me.uk> To: <boost@lists.boost.org> Sent: Saturday, January 08, 2005 9:39 AM Subject: [boost] Re Singleton
I realize now that there is little interest in considering my library for Boost over an adaptation of the Loki library... however, even if my implementation is not under consideration, would someone be willing to explain what advantages Loki offers over it?
The key thing that Loki does is use modern C++ design methods to allow a policy driven choice of a number of design questions. These are:
1) The Creation Policy - this can mean creation from new, malloc, or create statically. 2) The Lifetime Policy - this can mean that you use a Phoenix Singleton, Longevity managed singleton, or just using normal C++ rules. 3) The threading policy - single or multi-threaded.
The key disadvantage of your implementation (in my view) is that it forces the use of a single creation policy (create statically), a single lifetime policy (dependencies), and a single threading policy (single-threaded). Whilst it would be relatively easy to change any of these, it would involve re-writing the class, which moves away from the concept of generic, re-usable code.
While this is a response to a somewhat out-of-date message, I have read the latest contributions. This is just the most relevant to what I am about to add. Why does the "singleton" concept become a type that only ever has the one instance? I know this sounds ridiculous but I have stumbled onto this issue a few times and it continues to irritate me. One of the approaches to singletons goes something like; struct very_important_object {}; very_important_object & single_instance() { static very_important_object *p = new very_important_object; return *p; } This is not presented as the One-True-Singleton-Strategy, but simply as a technique that doesnt place the enforcement of singleton in the type. Why would you ever have more than one singleton? <embarrassed grin> Imagine that you are writing a PBX. There are several major components to this (exactly which depends on the standard you are following) and sensibly these components are to be implemented as singletons. Imagine that the type-equals-only-instance approach was adopted. Further imagine that the implementation all goes swimmingly. Then one day you are asked to produce a self-verifying version of your switch that runs two instances side-by-side. Or you are asked to do some call-setup performance testing, i.e. you need to run two instances of your PBX against each other. Or you need to perform soak testing that needs 6 instances in a single executable. And so on. Should the abstraction known as Singleton truly preclude there ever being more than 1 instance? Hopefully this list of possibilities has enough substance to it. And captures what I am trying to say ;-) Otherwise I am going to feel quite silly. Sometimes the type-equals-only-instance is a royal pain? Cheers, Scott