Re: [boost] [review] Fast track review of Boost.Utility/Singleton begins today

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-18 08:50:46

Pierre-Jules Tremblay wrote:
> On Jan 16, 2008 3:15 AM, Tobias Schwinger <tschwinger_at_[hidden]> wrote:
>> thank you for your review.
> 
> You are most welcome.  Thank you for your response to my comments.

Thanks again. This one was an interesting read, too.

> 
>>> For instance, the design
>>> could be made more flexible by allowing thread-safety to be specified as a
>>> policy (with appropriate default) or by delegating the responsibility to the
>>> wrapped type.
>> OK, FWIW policies complicate things. And what's their benefit here?
> 
> In some cases, policies do complicate things.  For instance, while I
> have marveled at the Loki Singleton implementation, it is at one
> extreme of the general-purpose design spectrum and I'm not willing to
> pay the price (in complexity). 

Yep. I did my best to avoid a Loki-style design.

>>> The solution to the OOI problem does not scale, and I would go as far as
>>> saying that it doesn't work in practice.  In my experience, it's a constant
>>> maintenance nightmare to try and keep the various slot assignments in the
>>> correct order (I have to deal with a large number of singletons; yes that is
>>> a problem in and of itself - this library will do nothing to discourage
>>> it).
>> You must have misunderstood the docs. OOI is not done with slots. The
>> slots are to prevent unnecessary resurrection during destruction.
> 
> Okay, I should have said "OOD" (order of destruction) instead.  So
> reading the documentation:
> 
>  Singleton instances are normally destroyed in reverse order of their
> construction, that is for a group of Singletons with their integral
> DisposalSlot template arguments being equal, where the destruction of
> these groups is ordered by the ascending DisposalSlot values.  We
> could raise the DisposalSlot  value of global_log from the previous
> examples to make sure it outlives other singletons that use 0 (the
> default): (...)
> 
> That, to me, sounds like the slot mecanism is for handling
> dependencies, in which case one must be careful in selecting which
> singletons fit in which slot.

Well, it's a means to override a default behavior that should just work
in a majority of cases:

o  Reverse order of construction, and
o  resurrection.

>>> Finally, this may constitute a minority opinion but I like to consider
>>> global access and single instance as orthogonal concepts.  One may want to
>>> ensure a resource is only instantiated once without necessarily providing
>>> global access to that resource.
>> So Singletons should be dynamic arrays in your opinion?
> 
> I'm not sure what you mean, and I haven't had coffee yet so perhaps
> that's why ;-).  How do dynamic arrays help separate the concepts of
> preventing a second instantiation and global access to the first
> instance?

They allow more instances at one global access point.

Regards,
Tobias