Re: [boost] Re Singleton

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.

-Jason