Boost logo

Boost :

From: Jason Hise (chaos_at_[hidden])
Date: 2005-01-24 12:13:54


Dave Handley wrote:

>Jason Hise wrote:
>
>
>
>>Pavel and I have been discussing a sibling class to the singleton,
>>namely a multiton. Such a class would manage a unique object instance
>>for each key provided to GetInst. It should be able to use many of the
>>same policies that the singleton uses.
>>
>>Pavel thinks that it could be useful to allow GetInst to take any number
>>of parameters. Would this actually be useful, and if so, how could such
>>a design be achieved?
>>
>>
>>
> <>
> I think that "multitons" are very useful - but I'm not sure that a
> Singleton class should necessarily be bloated out to support them.

I agree entirely... which is why I plan to make multiton a sibling class
instead of making the singleton support it with additional policies. It
will live in the same namespace and possibly be able to utilize some of
the same policies that the singleton does (for instance any allocator
that doesn't restrict creation to one instance)

> <> The way I have normally implemented this type of structure is to have
> a class that is itself a singleton, but is responsible for generating
> and returning one of a fixed (or variable) number of classes. If you
> implement the interface through a static function that delegates
> through the singleton GetInst function, you get a very simple
> interface which doesn't detract from a nice simple singleton interface
> - eg:
>
> class Multiton : public Singleton<Multiton>
> {
> public:
> class Child;
> static Child *GetInst( int number ) { return GetInst()->GetChild(
> number ); }
> private:
> Child *GetChild( int number ) { // TODO: check for and return the
> correct instance of Child }
> };
>
> Is this pretty much what you were thinking?

Almost. The key passed in to GetInst would be templated, and Child
would be the multiton itself. However, upon further meditation I wonder
if having Child a separate type would be preferable. I guess the
question at hand is how important it is to enforce that there can only
be instances that correspond to a key. With your model, anyone could
easily instantiate a Child.

-Jason


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk