Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-17 13:26:06

Anthony Williams wrote:
> Tobias Schwinger <tschwinger <at>> writes:
>> In fact, "just creating one" should be exactly what this library is all
>> about .
> Singleton is also called the Highlander pattern --- there can be only one.

Cool! I think I'll rename the library when it gets accepted :-P.

>> OK. With a Singleton, the type serves as the key to access the global
>> which I personally find quite elegant.
> and which I find to be the biggest problem with singletons.

I see. And it seems to me that you overrate the problem part of it.

>> A singleton can easily hold several instances of any other class, if a
>> container is put into it.
>> Further you can use multiple-inheritance to instantiate many singletons
>> with a common subobject at compile time.
>> So what are the alternatives (concrete interface proposals, please)?
> One of the benefits you cite for your singleton design is the
> construction-on-demand, which ensures that things are always constructed when
> required. In that case, how about providing a class:
> template<typename T>
> class construct_on_demand;
> so you can create instances like:
> construct_on_demand<Logger> myLogger;
> and any call to myLogger->log() will ensure that the object is constructed
> before first use.
> The appropriate operator-> call can also manage destruction order if required.


Now let's see how we'd do it with Singletons:

     class Logger;

     struct myLogger : Logger, boost::singleton<myLogger> {};
     // Please note that:
     // o We do not waste BSS space, and
     // o the instance can be allocated statically.

OK, we use a type instead of the variable name. So what?!

>>>> What is the point of having more than one instance of a class that lives
>>>> in static context -- and how would it be captured syntacticly?
>>> I can imagine a use for having lots of instances of boost::mutex at global
>>> scope --- each mutex protects a different thing. You don't need to capture
>>> the
>>> syntactic idea "there may be more than one of this class" --- that is the
>>> base
>>> level assumption.
>> Interestingly, you show us that in this very case the things you try to
>> protect should be 'mutexed_singleton'S to avoid namespace pollution and
>> to add clarity .
> That was the first thought off the top of my head. It may be that a Locked<T>
> template (such as that mentioned by Phil Endecott) would be a good idea, but
> even then you've got multiple instances of the Locked<> template at global
> scope. My point is that just because something is a global doesn't mean you only
> want one instance of that *class*.

Yes, I do understand your point. I don't believe it is that important,
however :-).


Boost list run by bdawes at, gregod at, cpdaniel at, john at