Re: [boost] Re Singleton

From: Scott Woods (scottw_at_[hidden])
Date: 2005-01-09 19:23:22

----- Original Message -----
From: "Dave Handley" <dave_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, January 08, 2005 9:39 AM
Subject: [boost] Re Singleton

> > I realize now that there is little interest in considering my library
> > for Boost over an adaptation of the Loki library... however, even if my
> > implementation is not under consideration, would someone be willing to
> > explain what advantages Loki offers over it?
> >
>
> The key thing that Loki does is use modern C++ design methods to allow a
> policy driven choice of a number of design questions.  These are:
>
> 1)    The Creation Policy - this can mean creation from new, malloc, or
> create statically.
> 2)    The Lifetime Policy - this can mean that you use a Phoenix
Singleton,
> Longevity managed singleton, or just using normal C++ rules.
> 3)    The threading policy - single or multi-threaded.
>
> The key disadvantage of your implementation (in my view) is that it forces
> the use of a single creation policy (create statically), a single lifetime
> policy (dependencies), and a single threading policy (single-threaded).
> Whilst it would be relatively easy to change any of these, it would
involve
> re-writing the class, which moves away from the concept of generic,
> re-usable code.

While this is a response to a somewhat out-of-date message, I have read
the latest contributions. This is just the most relevant to what I am
about to add.

Why does the "singleton" concept become a type that only ever has the
one instance? I know this sounds ridiculous but I have stumbled onto this
issue a few times and it continues to irritate me.

One of the approaches to singletons goes something like;

struct very_important_object {};

very_important_object &
single_instance()
{
    static very_important_object *p = new very_important_object;
    return *p;
}

This is not presented as the One-True-Singleton-Strategy, but simply as
a technique that doesnt place the enforcement of singleton in the type.

Why would you ever have more than one singleton? <embarrassed grin>

Imagine that you are writing a PBX. There are several major
components to this (exactly which depends on the standard you
are following) and sensibly these components are to be implemented
as singletons. Imagine that the type-equals-only-instance approach was
adopted. Further imagine that the implementation all goes swimmingly.

Then one day you are asked to produce a self-verifying version
of your switch that runs two instances side-by-side. Or you are
asked to do some call-setup performance testing, i.e. you need
to run two instances of your PBX against each other. Or you
need to perform soak testing that needs 6 instances in a single
executable. And so on. Should the abstraction known as Singleton
truly preclude there ever being more than 1 instance?

Hopefully this list of possibilities has enough substance to it. And
captures what I am trying to say ;-) Otherwise I am going to feel
quite silly.

Sometimes the type-equals-only-instance is a royal pain?

Cheers,
Scott