From: Jason Hise (chaos_at_[hidden])
Date: 2005-01-07 17:39:40
Dave, thank you for your reply.
Dave Handley wrote:
> The key disadvantage of your implementation (in my view) is that it
> forces the use of a single creation policy (create statically)
Since my revision, the singleton is not forced to be created
statically. Singleton A will only be created statically if client code
creates a static dependency on A, or if another singleton B has a static
lifetime and depends upon A. If the actual method of allocation (new)
should be made more flexible, would adding a template allocator
parameter similar to that used by stl containers be sufficient?
> ...a single lifetime policy (dependencies)
Again, because I removed the enforced static dependency that was in the
original code, my singleton should allow multiple lifetime types based
on where and how dependencies are used.
> and a single threading policy (single-threaded).
This is accurate, and I do not know how it could be portably resolved.
Hopefully when Alexandrescu's book gets here I will get some insight on
how this was resolved in Loki.
> I would much prefer to see the curiously recurring template pattern
> (CRTP) being used. For your info, if you are not familiar with CRTP
> then you would have a new singleton called MySingleton that looked
> something like:
> class MySingleton : public generic_singleton<MySingleton> etc.
> The generic_singleton class can then enforce protected
> constructors/destructors and private copy constructors/equals operators.
I was not aware that making a base class's ctors and dtors protected
would prevent client code from instantiating a derived class that
chooses to make its ctors and dtors public. Now aware of this, I fully
agree that such an organizational structure would be preferable to my own.
> Dependencies are certainly one way of managing the lifetime of a
> singleton, but in a large project you would need to be aware of some
> potential flaws which your implementation would not pick up.
> Specifically, if you accidentally created a cycle of dependencies, the
> Singletons will never be destroyed. This is an easy thing to pick up
> in a small project, but in a large project maintained with lots of
> programmers over a number of years, I can guarantee that this will
> happen at some point.
Doesn't the same potential problem exist with ref-counted smart
pointers? Wouldn't it be accurate to say that it should be illegal to
create singletons with cyclic dependencies in the first place? With my
current design, just getting a pointer to the singleton introduces a
dependency. Thus, if a singleton B requires access to a singleton A for
only certain function calls, it should simply get access to the pointer
to A's instance at the beginning of those function calls. A singleton
should only own a dependency to another singleton if it actually
requires it for its entire lifetime, so cyclic dependencies simply don't
make sense to write.
> This is one of the reasons for a longevity based system in Loki - it
> doesn't matter if you get 2 singletons with the same longevity since
> they will just be deleted in reverse order of creation.
Hard coding a longevity number for each singleton seems dangerous to me,
because it is difficult to see what order all the singletons would be
created in without tracking each down and looking at it. Any time a new
singleton is added, many of the numbers might need to be shuffled.
Explicitly owning a dependency or getting the instance seems more
intuitive to me as to document what the singleton actually requires.
> Your solution isn't wrong, its just that Loki does a whole lot more
> that makes it a better library.
Hopefully, after rearranging my code into CRTP form and adding a
template parameter to control allocation and deallocation, the only real
drawback to my library will be its lack of support for different
threading models. After reading up on how Loki achieved this, I will
try to integrate it as well. Again, thank you for your feedback.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk