This question already has answers here:
How is Meyers' implementation of a Singleton actually a Singleton
(2 answers)
Closed 4 years ago.
A coworker and I were discussing about how to make a singleton and it turns out we're doing it differently.
My singleton :
class Singleton
{
public:
static Singleton* getInstance()
{
if(!instance) instance = new Singleton();
return instance;
}
~Singleton()
{
if(instance) delete instance;
}
private:
Singleton() {}
static Singleton* instance;
};
His singleton :
class Singleton
{
public:
static Singleton& getInstance()
{
static Singleton instance;
return instance;
}
private:
Singleton() {}
};
These examples are of course simplified for reading purposes. I like his solution because it is shorter and somehow more elegant, but something bugs me...
When his getInstance() method returns the instance, aren't we leaving the scope where it was declared and destorying it? How do you explain it's lifetime beyond the return?
You need to review storage classes in C++.
Any object declared as static (or extern) has static storage and gets destructed at the end of program in the reverse order of construction.
The order of construction of naked static objects is not deterministic and troublesome, especially in multi threading.
Function local static Objects(AKA Scott Meyer's singletons) OTH are ALAP constructed on first call to the owning function, and since C++11 in a magically thread safe manor(ie. no double construction).
I would add following declarations to your friend's class to make the singleton actually single:
class Singleton{
//...
Singleton(Singleton const&)=delete;
Singleton(Singleton&&)=delete;
auto& operator=(Singleton const&)=delete;
auto& operator=(Singleton &&)=delete;
};
Related
When using the Meyers singleton:
class Singleton
{
public:
static Singleton& instance()
{
static Singleton instance;
return instance;
}
void Hello()
{
std::cout <<"Hello!\n";
}
protected:
Singleton() = default;
~Singleton() {};
private:
Singleton(Singleton const&);
Singleton& operator=( Singleton const& );
};
You are able to call the instance as follow:
Singleton::instance().Hello();
or
Singleton& s = Singleton::instance();
s.Hello();
But I'm wondering if there is a way to block this:
Singleton::instance().instance();
How to avoid to call instance() as a method (with the .) and only support the static call with the :: ?
Is there a way to use static_assert, template enable_if or anything else?
First, I don't think this is a practical concern. Nobody is going to write Singleton::instance().instance().instance().Hello(). Or rather, if people are writing that on purpose, I think you have bigger problems. This is fine, as-is.
If you really want to prevent that, then you just have to move instance() outside of the class so it ceases to be a member function. There's nothing for you to assert or constrain, since you cannot tell if your static member function was called on an object or not (and you cannot overload a static member function with a non-static one taking the same argument list). Either you can write both Singleton::instance() and Singleton::instance().instance(), or neither.
Simplest is just:
class Singleton {
// ...
friend Singleton& make_singleton();
};
Singleton& make_singleton() {
static Singleton instance;
return instance;
}
Now it's just make_singleton().Hello(), and there's no other way to write that at all. This can be arbitrarily generalized by wrapping it in a singleton class template factory:
template <typename T>
struct SingletonFactory
static T& instance() {
static T instance;
return instance;
}
};
SingletonFactory<Singleton>::instance().Hello(); // ok
SingletonFactory<Singleton>::instance().instance().Hello(); // error
I know that the singleton pattern is usually considered a bad design and hence discouraged, but this question concerns the implementation aspects, not the appropriateness of the singleton pattern.
Consider the following three implementations of a singleton in C++ using lazy initialization:
1: Using pointer, split between declaration and implementation
Singleton.hpp:
class Singleton {
public:
static Singleton* instance();
private:
Singleton() {}
static Singleton* singleton;
};
Singleton.cpp:
Singleton* Singleton::singleton = nullptr;
Singleton* Singleton::instance() {
if( nullptr == singleton ) {
singleton = new Singleton();
}
return singleton;
}
2: Using reference, split between declaration and implementation
Singleton.hpp:
class Singleton {
public:
static Singleton& instance();
private:
Singleton() {}
};
Singleton.cpp:
Singleton& Singleton::instance() {
static Singleton singleton;
return singleton;
}
3: Using reference, inline in declaration
Singleton.hpp:
class Singleton {
public:
static Singleton& instance() {
static Singleton singleton;
return singleton;
}
private:
Singleton() {}
}
I personally like and use the third version. But is there any good reason to prefer the first or the second version instead?
It is my understanding that in the third version there is an instance of the object for each translation unit that includes Singleton.hpp and then the linker picks a single one. Does this causes any side effect?
And are there any side effects using the third one in a shared library?
Bonus questions: which implementation is actually the "Meyer's singleton"?
The first one is not thread safe.
if( nullptr == singleton ) {
singleton = new Singleton();
}
It could happen that multiple threads could execute the allocation statement and create a memory leak.
The second and the third ones are thread-safe since C++11, because:
If multiple threads attempt to initialize the same static local
variable concurrently, the initialization occurs exactly once (similar
behavior can be obtained for arbitrary functions with std::call_once).
from here.
I'd prefer the third one because the inline optimisations are more likely.
Under these condition i wrote the next Singleton class :
1 - i want one and only one instance of the class to be present and to be accessible from the whole game engine .
2 - the Singleton is intensively used ( thousands times per frame) so i dont want to write an extra GetInstance() function , im trying to avoid any extra function call for performance
3 - one possibility is to let the GetInstance() be inlined like this :
inline Singleton* Singleton::GetInstance()
{
static Singleton * singleton = new Singleton();
return singleton;
}
but that will cause a reference problem , on each call there will be a new reference to the singleton , to fix that wrote in c++ :
class Singleton{
private:
static Singleton* singleton;
Singleton(){}
public:
static inline Singleton* GetInstance() // now can be inlined !
{
return singleton;
}
static void Init()
{
// ofc i have to check first if this function
// is active only once
if(singleton != nullptr)
{
delete singleton;
}
singleton = new Singleton();
}
~Singleton(){} // not virtual because this class can't be inherited
};
Singleton* Singleton::singleton = nullptr;
What are the possible problems i can face with this implementation ?
Your first implementation problem is a leak of the only new you call.
And the signature that force user to check pointer validity.
Your second implementation has even more problem as you require to use a 2-step initialization, and don't forbid copy/move/assignment.
Simply use Meyers' singleton:
class Singleton{
private:
Singleton() = default;
~Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton operator&(const Singleton&) = delete;
public:
static Singleton& GetInstance()
{
static Singleton instance;
return instance;
}
};
In addition to #Jarod42's answer, I would like to point out that you could also implement a generic singleton by making template and use it in a CRTP class:
template<typename T>
class Singleton {
protected:
Singleton() = default;
~Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton operator&(const Singleton&) = delete;
public:
static T& instance() {
static T instance;
return instance;
}
};
Then extend it:
struct MySingleton : Singleton<MySingleton> { /* ... */ };
Instead of a singleton, consider a namespace! Here's how I would do it:
// thing.h
namespace thing {
// public interface
int doSomething();
}
// thing.cpp
namespace thing {
namespace {
// private data and functions can go right here :-)
int private_data_ = 1234;
int doSomethingInternal() {
return private_data_ * 2;
}
}
// public interface
int doSomething() {
return doSomethingInternal();
}
}
Usage is simple like this:
int x = thing::doSomething();
No need for getInstance(), no memory leaks, and you can't accidentally make multiple instances.
but that will cause a reference problem , on each call there will be a new reference to the singleton
Incorrect; instead there will be a new class instance which is not the same as a reference. You will most likely end up leaking memory.
static Singleton* singleton;
Use a unique_ptr instead of a raw pointer. Compiler optimizations will devolve it into a raw pointer anyway, but now you're clearly telling the compiler what its lifespan should be.
class Singleton{
private :
static Singleton* singleton;
The default scope of a class is private; you don't need to explicity say private scope.
Singleton(){}
There is no need to provide an empty constructor when you have no other constructors in the class.
im trying to avoid any extra function call for performance
Compiled C++ will often inline such code anyway.
inline Singleton* GetInstance() // now can be inlined !
Make it static...?
~Singleton(){} // not virtual because this class can't be inherited
If your intent is to make it not inheritable, then add a final keyword to the class declaration. You can then remove the destructor.
I like to experiment around as I learn more about coding. I have a program that would only require a single instance of a struct for the life of it's runtime and was wondering if it's possible to create a singleton struct. I see lot's of information on making a singleton class on the internet but nothing on making a singleton struct. Can this be done? If so, how?
Thanks in advance. Oh, and I work in C++ btw.
A class and a struct are pretty much the same thing, except for some minor details (such as default access level of their members). Thus, for example:
struct singleton
{
static singleton& get_instance()
{
static singleton instance;
return instance;
}
// The copy constructor is deleted, to prevent client code from creating new
// instances of this class by copying the instance returned by get_instance()
singleton(singleton const&) = delete;
// The move constructor is deleted, to prevent client code from moving from
// the object returned by get_instance(), which could result in other clients
// retrieving a reference to an object with unspecified state.
singleton(singleton&&) = delete;
private:
// Default-constructor is private, to prevent client code from creating new
// instances of this class. The only instance shall be retrieved through the
// get_instance() function.
singleton() { }
};
int main()
{
singleton& s = singleton::get_instance();
}
Struct and class are in C++ almost the same (the only difference is default visibility of members).
Note, that if you want to make a singleton, you have to prevent struct/class users from instantiating, so hiding ctor and copy-ctor is inevitable.
struct Singleton
{
private:
static Singleton * instance;
Singleton()
{
}
Singleton(const Singleton & source)
{
// Disabling copy-ctor
}
Singleton(Singleton && source)
{
// Disabling move-ctor
}
public:
Singleton * GetInstance()
{
if (instance == nullptr)
instance = new Singleton();
return instance;
}
}
Conceptually, a struct and a class are the same in C++, so a making singleton struct is the same as making a singleton class.
The only difference between class and struct are the default access specifiers and base class inheritance: private for class and public for struct. For example,
class Foo : public Bar
{
public:
int a;
};
is the same as
struct Foo : Bar
{
int a;
};
So, there is no fundamental difference when it comes to singletons. Just make sure to read about why singletons are considered bad.
Here's a simple implementation:
struct singleton
{
static singleton& instance()
{
static singleton instance_;
return instance_;
}
singleton(const singleton&)=delete; // no copy
singleton& operator=(const singleton&)=delete; // no assignment
private:
singleton() { .... } // constructor(s)
};
First off, struct and class only refer to the default access of members. You can do everything with a struct that you can do with a class. Now if you were referring to POD structs, things get more complicated. You can't defined a custom constructor, so there's no way to enforce only a single object creation. However, there's nothing stopping you from simply only instantiating it once.
class and struct is almost a synonyms in C++. For singleton use case they are complete synonyms.
Is it compulsory to have a private destructor for a singleton class.
If the singleton is implemented as a variable at global scope, it must have a public destructor. Only public members are accessible at global scope.
If it's declared as a static member or static local within its own class, then the destructor may be private. The destructor is called from within class scope, where it is accessible, when the program exits. That is one way to enforce the object being a singleton. Do you need to strongly enforce that? If so, yes. It depends what you mean by "compulsory."
class A{
private:
~A() {}
public:
static A &getGlobalA() {
static A a2; // <- or here - better technique
return a2; // this is initialized upon 1st access
}; // and destroyed on program exit
static A a; // <- constructor, destructor accessed from here
};
A A::a; // <- but "called" from here in terms of control flow
This might not be what you are looking for.. But for reference, I use it as follows:
// .h
class Foo {
public:
static Foo* getInstance();
static void destroy();
private:
Foo();
~Foo();
static Foo* myInstance;
};
// .cpp
Foo* Foo::myInstance = NULL;
Foo* Foo::getInstance(){
if (!myInstance){
myInstance = new Foo();
}
return myInstance;
}
void Foo::destroy(){
delete myInstance;
myInstance = NULL;
}
Then at the end of my program, I call destroy on the object. As Péter points out the system will reclaim the memory when your program ends, so there is no real reason. The reason I use a destroy is when Ogre complained that I hadn't released all the memory I allocated. After that I just use it as "good manner", since I like cleaning up after myself.
In my opinion, the destructor of a signleton should be private. Otherwise somewone is able to call 'delete' for your singleton instance. I know, normally nobody will do it. But if we talk about excellence design, it must be resistant to all possible intended or unitnended damages.
With the modern C++ it is allowed to declare even private destructors for statically constructed objects.
Here is my code snippet for Singleton:
class Singleton
{
public:
static Singleton& GetInstance();
// Before C++ 11
private:
Singleton() {}
~Singleton() {}
Singleton(const Singleton&); // Without implementation
Singleton& operator=(const Singleton&); // Without implementation
// Since C++ 11
private:
Singleton() = default;
~Singleton() = default;
public:
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};
Singleton& Singleton::GetInstance()
{
static Singleton instance;
return instance;
}
All classes have a destructor. If you don't create one the compiler will do so for you. So your question can be reworded to: Does the destructor for a singleton class have to private?
The simple answer is no, it doesn't have to be.
A more interesting question: Is it a good idea to make the destructor of a singleton class private?
Yes, in general, it is a good idea. If you make it private then your client code won't call the destructor by accident. Calling the destructor would cause the singleton to fail for all clients as the instance would become invalid.
No, and in general objects in C++ are not given private destructors. Keep in mind that Singleton means that there is only one instance, and so it is construction, not destruction, that needs to be controlled / prevented. Usually a singleton has a private constructor, a public destructor, a private static instance variable, and a public static singleton get / lazy construction function, although there are variations on that pattern.
You may return reference to your singleton instance.
class Factory : public IFactory
{
private:
/**
* This class should not be instantiated through its constructor. Since, it implements
* Singleton pattern.
*/
Factory();
public:
virtual ~Factory();
/**
* Accessor method for singleton instance.
* \note use this static method to access to operations of this class.
*/
static IFactory& instance(){
if(!m_instance.get()){
m_instance.reset(new Factory());
}
return static_cast<IFactory&>(*m_instance);
}
/**
* \see IFactory::create
*/
virtual boost::shared_ptr<IConnector> create();
private:
/* Singleton instance */
static boost::scoped_ptr<Factory> m_instance;
};
Having a private destructor as part of a singleton is not required from a programmer's point of view, but essential from a design point of view.
It avoids misuse of the class.
However, if you add a private destructor, you have to instantiate your class:
In a function / method: because if you create it as a global variable, you lose the interest of using a singleton (created to avoid global variables).
With the correct way to instantiate it: if your destructor is private, your class could not be deleted at the end of your program if you instantiate it as a "classic" local variable, because it can't access to it. So you have to instantiate it like this :
Singleton * potatoe = &Singleton::getInstance();
Here, we create a weak pointer named "potatoe", wich correspond to the address of the result of the "getInstance" function.
The consequence is that the destructor will not be called at the end of the function. But because (in "getInstance") the variable is declared "static" in a "static" method, the destructor will be called at the end of the program, without you having to do it.
Here is my code. Feel free to comment it.
// "class.hpp" file
class Singleton {
public:
static Singleton& getInstance() {
static Singleton S;
return S;
}
private:
Singleton();
~Singleton();
};
// "main.cpp" file
#include "class.hpp"
int main()
{
Singleton * patatoe = &Singleton::getInstance();
Singleton * tomatoe = &Singleton::getInstance();
Singleton * salad = &Singleton::getInstance();
return 0;
}