Would the following code facilitate lazy initialization?
Or would the singletonInstance be created as soon as somebody includes the header (or even at program startup time)?
class SingletonClass
{
private:
SingletonClass();
~SingletonClass();
public:
static const SingletonClass& Instance()
{
static SingletonClass singletonInstance;
return singletonInstance;
}
};
This is known as the Meyers singleton and they are lazy instantiated.
There are some considerations:
the singletons will be destroyed at the end of the program in the reverse order in which they are created, so there can be dependency issues.
C++03 doesn't guarantee against race conditions in multithreaded environments.
The SingletonClass constructor will not be called earlier than somenone calls the Instance() method.
Thus yes, it facilitates lazy initialization.
Related
If I return a reference to my instance of MySingleton from GetInstance() instead of the pointer in my code below, it will be valid, but is using the pointer in this way also valid?
I assume my pointer will only get initialized once because it is static, but not not sure.
I know the correct way by using raw pointers within a singleton is to check if the pointer is first null before assigning it, but wondering if the below code is also valid. Thanks
class MySingleton
{
public:
static MySingleton* GetInstance()
{
static MySingleton* inst = new MySingleton();
return inst;
}
private:
MySingleton(){};
};
EDIT: I haven't seen this exact implementation for a Singleton implemented in the reported duplicate question
Your implementation is acceptable (as is any other) as long as any one of the following holds:
Your singleton does not acquire any external resources (anything: file handles, network connections, shared memory) for longer than a single exception-safe method invocation.
The last user of your singleton deletes the instance manually.
Otherwise something serious can leak.
You can wrap the instance in something automatic, like std::unique_ptr, but this immediately casts usual singleton lifetime issues.
See std::call_once and std::once_flag for implementing singleton pattern. Your implementation will lead to troubles in a multithreaded environment.
Most of is seem to have missed the simplest possible form of C++ singleton AKA Scott Meyer's Singleton. Ever since C++11 it has become as easy as a pie:
class singleton{
singleton();
singleton(singleton&&)=delete;
singleton(singleton const&)=delete;
void operator(singleton&&)=delete;
void operator(singleton const&)=delete;
//...
public:
static auto& singleton::instance(){
static singleton val{};
return val;
}
};
No need for complex code.
I will demonstrate my question using a Singleton pattern but it is a broader question. Please spare me the "Singletons are evil" lectures.
Version 1 of Singleton
class Singleton
{
public:
static Singleton& getInstance()
{
static Singleton instance; // This becomes a class member in Ver.2
return instance;
}
private:
// Constructor, forbid copy and assign operations etc...
}
Version 2 of Singleton
class Singleton
{
public:
static Singleton& getInstance()
{
return instance;
}
private:
static Singleton instance; // I'm here now!
// Constructor, forbid copy and assign operations etc...
}
I will now explain what I think will be the difference is between the two:
Version 1 instance will only be initialized once the flow of the program reaches the actual definition of instance (i.e some part of the program requests an instance using Singleton::getInstace()). Lazy instantiated in other words.
It will only be destroyed when the program terminates.
Version 2 instance will be initialized at the start of the program, before main() is called. Will also be destroyed only when the program terminates.
First of all, am I correct in the above assumptions?
Second, Is this behavior of initialization universal (say for global variables and functions)?
Last, Are there any other nuances I should be alerted about concerning this?
Thanks!
You are correct.
You should also notice that the 2nd version does not guarantee when will the object be created, only that it will be before the main function is called.
This will cause problems if that singleton depends on other singletons and etc
That is, the first version will give you greater control over your code, initialization order and of course - less bugs :)
someone told me just to write singleton as a local class, is that true?
I am wondering why using the local class can ensure thread safety.
#include <boost/utility.hpp>
class singleton : private boost::noncopyable {
public:
static singleton& instance() {
static singleton inst;
return inst;
}
private:
singleton() = default;
~singleton() = default;
};
The construction of local static variables is guaranteed to be thread-safe.
Also, avoid singletons at all cost. They are just as terrible as globals are.
Take a look at this post: what is correspoding feature for synchronized in java?feature-for-synchronized-in-java
Basically it states that C++ doesn't has a language level feature for locking mechanisms, wich you need to make your singelton class threadsafe, though this articel http://en.wikipedia.org/wiki/Double-checked_locking about the Double Checked Locking Pattern states, that no locking is needed for singletons (an example is included for c).
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.
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 a singleton, since it's can be created by anyone
I need not repeat the good point about lazy construction of the singleton made in other answers.
Let me add this:
public:
Singleton();
virtual ~Singleton() {}
The designer of this particular class felt a need to allow:
derivation from this Singleton class, say the derived class is called DerSingleton
DerSingleton can have instances which can be deleted with a pointer to Singleton (so DerSingleton is not a singleton)
Any instance of DerSingleton is also a Singleton instance by definition, so it follows that if DerSingleton is instanciated, Singleton is not a singleton.
So this design asserts two things:
this class is a singleton
this class is not a singleton
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.
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.
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
When I look for informations about the singleton pattern for C++, I always find examples like this:
class Singleton
{
public:
~Singleton() {
}
static Singleton* getInstance()
{
if(instance == NULL) {
instance = new Singleton();
}
return instance;
}
protected:
Singleton() {
}
private:
static Singleton* instance;
};
Singleton* Singleton::instance = NULL;
But this kind of singleton also seems to work as well:
class Singleton
{
public:
~Singleton() {
}
static Singleton* getInstance()
{
return &instance;
}
protected:
Singleton() {
}
private:
static Singleton instance;
};
Singleton Singleton::instance;
I guess that the second singleton is instantiated at the beginning of the program, unlike the first, but is it the only difference?
Why do we find mainly the first?
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14
The static initialization order fiasco is a very subtle and commonly
misunderstood aspect of C++. Unfortunately it's very hard to detect —
the errors often occur before main() begins.
In short, suppose you have two static objects x and y which exist in
separate source files, say x.cpp and y.cpp. Suppose further that the
initialization for the y object (typically the y object's constructor)
calls some method on the x object.
That's it. It's that simple.
The tragedy is that you have a 50%-50% chance of dying. If the
compilation unit for x.cpp happens to get initialized first, all is
well. But if the compilation unit for y.cpp get initialized first,
then y's initialization will get run before x's initialization, and
you're toast. E.g., y's constructor could call a method on the x
object, yet the x object hasn't yet been constructed.
The first method you listed avoids this problem completely. It's called the "construct on first use idiom"
The downside of this approach is that the object is never destructed.
There is another technique that answers this concern, but it needs to
be used with care since it creates the possibility of another (equally
nasty) problem.
Note: The static initialization order fiasco can also, in some cases,
apply to built-in/intrinsic types.
The first one allows you to delete the instance while the second one does not. But please be aware that your first example is not thread safe
It's commonly known as the static initialization order fiasco. In summary, static instances at file scope are not necessarily initialized before explicit function calls that create one as in your first example.
The singleton patterns is commonly considered Bad Practice, so empirical evidence (what you "see most") is of little value in this case.
The first version uses dynamic allocation, while the second one uses static allocation. That is, the second allocation cannot fail, while the first one could possibly throw an exception.
There are pros and cons to both versions, but generally you should try for a different design that doesn't require singletons at all.
The first one is also "lazy" - it will be created only if and when it is needed. If your Singleton is expensive, this is probably what you want.
If your Singleton is cheap and you can deal with undefined order of static initialization (and you don't use it before main()), you might as well go for the second solution.