Re: [boost] Re: Work in progress list? And how about a singleton?

From: Mattias Flodin (flodin_at_[hidden])
Date: 2001-11-15 10:39:30

On Wed, 14 Nov 2001, Peter Dimov wrote:
> _I_ don't need one provided that I can (easily) make the above thread safe.
> This is not yet covered by Boost to the extent that I'd have liked.
>
> But if we move from technical to psychological reasons, many developers
> think that a design pattern that has such a cool name absolutely needs to
> have an associated class (template.) The next trap they fall into, of
> course, is in thinking that making a global variable a 'Singleton' somehow
> makes it less global and hence, acceptable. ;-)

I'd say there are more psychological reasons than this. I like to be able
to express intent with source code rather than comments, when possible. In
that respect, this code clearly communicates that "A isa singleton":

class A : public singleton<A> {
  /* ... */
};

This would also be more clearly shown in an UML class hierarchy
chart, than if there is just an instance() method.

Reliability is another simple reason for a singleton: you put your trust
into singleton to handle whatever is necessary to make things work -
instead of rewriting the singleton code each time, which would be more
error-prone (especially when you need thread safety etc).

Furthermore there is a big difference between just a global variable and a
singleton, in that the singleton may defer instantiation to the user, and
thus provide a form of polymorphism. I may for instance have a virtual
class Application, with the functions run() and process_handle(), the
former being left to be implemented by the user:

class Application : public singleton<A> {
public:
    Handle process_handle();
    virtual int run()=0;
private:
    /* ... */
};

And the user would make a concrete class that she instantiates:

class MyApp : public Application {
public:
    int run() {cout << "Hello World!" << endl; return 0;}
};
MyApp app;

This would allow a library to make calls into the singleton, but have the
singleton defined by the user.

> Adding 'policies' simply means that the object is no longer a singleton, but
> something else.

IMHO policies are needed primarily because reality is not so theoretical
as one would like it to be. You may run into problems with lifetime when
you try to have several singletons that depend on each other. There are
efficiency concerns, such as avoiding mutex locks on every access if your
code does not need to be thread safe. And there's the issue of
initialization parameters to consider. I'd say a singleton is a singleton
even if it needs parameters (such as log file name) for initialization.

/Mattias

--
Mattias Flodin <flodin_at_[hidden]>   "A good thing about C++ is that only
Room D418                           friends can access your private parts"
Department of Computing Science
Umeå University
S-901 87 Umeå, Sweden
Note: Any opinions expressed in this mail are personal, and do not
necessarily reflect an official standpoint of Umeå University.