I usually implement the singleton pattern this way :
class Singleton
{
public:
virtual ~Singleton() {}
static Singleton& GetInstance()
{
static Singleton instance;
return instance;
}
private:
Singleton();
Singleton(const Singleton&);
Singleton& operator=(const Singleton&);
}
Recently, I ran into this implementation, which is slightly different :
class Singleton
{
public:
Singleton();
virtual ~Singleton() {}
static Singleton& GetInstance()
{
return instance;
}
private:
Singleton(const Singleton&);
Singleton& operator=(const Singleton&);
static Singleton instance;
}
Singleton Singleton::instance;
Which implementation is better ?
Isn't it dangerous not to make the constructor private (2nd implementation) ?
Thanks.
One important difference between the two is that the creation of the instance in the second example is thread-safe.
You're absolutely right though, the constructor should be private.
Here's a related question: https://stackoverflow.com/a/10479084/1158895
The second implementation is wrong. The default constructor should be private. As it is, it is not a singleton per se. Besides that, the differences between the implementations are mentioned in @Andrew and @Brady answers.
The main difference in behavior will come if you try to use the singleton during initialization of another namespace level variable or class static member. In the first case, because the actual object is created on demand during the first function call, the behavior during contruction will be well defined. In the second case, all bets are off, since the relative order of initialization of static objects from different translation units is undefined.
Also note that while the first one is safe during construction, it might not be during destruction. That is, if an object with static storage duration does not use the singleton during construction, it could be initialized before the singleton instance. The order of destruction is reversed from the order of construction, and in this particular case the singleton would be destroyed before the other object. If that object uses the singleton in its destructor, it will cause undefined behavior.
I need not repeat the good point about lazy construction of the singleton made in other answers.
Let me add this:
The designer of this particular class felt a need to allow:
Singleton
class, say the derived class is calledDerSingleton
DerSingleton
can have instances which can be deleted with a pointer toSingleton
(soDerSingleton
is not a singleton)Any instance of
DerSingleton
is also aSingleton
instance by definition, so it follows that ifDerSingleton
is instanciated,Singleton
is not a singleton.So this design asserts two things:
There is a difference. In first case
instance
is initialized on first call of the function. In second case it is initialized when program starts.If you make a
public
constructor - It's not asingleton
, since it's can be created by anyone