Re: Confused about a thread-safe singleton example.
On Dec 3, 4:25 pm, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
On 3 Dec, 18:12, Noah Roberts <u...@example.net> wrote:
Maxim Yegorushkin wrote:
On Dec 3, 4:59 pm, Noah Roberts <u...@example.net> wrote:
Maxim Yegorushkin wrote:
On Dec 3, 9:43 am, James Kanze <james.ka...@gmail.com> wrote:
1. Don't use singletons. Ever. Pretty much all of the value
of the GoF Design Patterns book is negated by the fact that
they chose to legitimize Singleton as a design pattern.
Singleton is just a fancy name for global variable. We should
call it the Global Variable (anti)Pattern.
And there are valid reasons for using it.
What are those reasons?
Some things must be inherently unique in a process.
This is what global variables are for.
Globals do not offer any protection against further instantiation. =
If
something must be unique then it should only be possible to create a
single variable of that type. How are you going to offer that wit=
h an
unprotected variable, a comment saying, "Don't make any of these..."=
?
[]
Using abstract classes (interfaces) and global references you can
achieve the desired effect.
That method does not work.
[]
Here is a proof that it works. Example of a type you can't instantiat=
e
and a global variable of that type:
// header.h begin
struct X
{
virtual void foo() = 0;
};
extern X& global_x;
// header.h end
// source.cc begin
#include "header.h"
namespace {
struct XImpl : X
{
void foo() {}
} x;
}
X& global_x = x;
// source.cc end
And look, you've just implemented a singleton. This isn't 'just' a g=
lobal.
A global variable by definition is a singleton, is it not?
Nay, it is not. The one key part of the singleton model that a global
variable does not satisfy is limiting the number of instances of a
class to 1. For example:
class ArbitraryClass {
public:
ArbitraryClass ();
};
extern ArbitraryClass g_instance;
There is a global variable, it's an instance of ArbitraryClass.
However, ArbitraryClass is not a singleton. Since more than one
instance of ArbitraryClass can exist, it is *not* using the singleton
model.
It is true that in many cases, a global instance and an instance of a
singleton class can be accessed in similar ways, but that does not
make the two the same. There are other points to the singleton model
besides just a globally accessible instance.
Singleton is an idea that there is only one object of some thing. In C+
+ it can be represented as global object, as SomeThing::instance(),
same pimpl / monostate, and likely there are more ways of representing
this idea.
Yes, singleton is an idea that there is only one instance of some
thing. Storing an instance of some arbitrary class in a global
variable, however, does not enforce that, and does not follow the
singleton model.
Singleton is undeniably a useful idea. My point is that representing
singletons as regular global objects looks to me more natural and
elegant than SomeThing::instance().
The problem is that a global variable does not sufficiently represent
a singleton, as it does not enforce that only one instance of the
class exists.
The matter of it looking more natural is, of course, a personal
preference. The SomeThing::instance() interface to a singleton
instance is idiomatic and easily recognizable.
May be because C++ is considered a
multi-paradigm language and SomeThing::instance() looks coming from
the object-oriented paradigm of it, whereas global variables feel
natural when using C++ both as a procedural programming language and
OO-language: just a regular variable with a large scope.
Singleton classes are different than a regular variable with a large
scope. The purpose of the singleton model is to limit the number of
instances of a class to 1. You don't even need to use the
Class::getInstance() interface, you only need to ensure that only a
single instance of the class exists at any given time. A global
variable alone has no effect on this requirement.
If you wanted to access the class through a global variable rather
than a function call, you'd have to go out of your way to make that
happen; perhaps, for example, by sticking to idiomatic singleton
implementations and assigning the single instance to a global
variable. There is no reason to do that, though.
Jason