As the title says. How would I create an instance of a class that is globally available(for example I have a functor for printing and i want to have a single global instance of this(though the possibility of creating more)).
Going to all the effort of making a singleton object using the usual pattern isn't addressing the second part of your question - the ability to make more if needed. The singleton "pattern" is very restrictive and isn't anything more than a global variable by another name.
// myclass.h
class MyClass {
public:
MyClass();
void foo();
// ...
};
extern MyClass g_MyClassInstance;
// myclass.cpp
MyClass g_MyClassInstance;
MyClass::MyClass()
{
// ...
}
Now, in any other module just include myclass.h and use g_MyClassInstance as usual. If you need to make more, there is a constructor ready for you to call.
First off the fact that you want global variables is a 'code smell' (as Per Martin Fowler).
But to achieve the affect you want you can use a variation of the Singleton.
Use static function variables. This means that variable is not created until used (this gives you lazy evaluation) and all the variables will be destroyed in the reverse order of creation (so this guarantees the destructor will be used).
class MyVar
{
public:
static MyVar& getGlobal1()
{
static MyVar global1;
return global1;
}
static MyVar& getGlobal2()
{
static MyVar global2;
return global2;
}
// .. etc
}
As a slight modification to the singleton pattern, if you do want to also allow for the possibility of creating more instances with different lifetimes, just make the ctors, dtor, and operator= public. That way you get the single global instance via GetInstance, but you can also declare other variables on the heap or the stack of the same type.
The basic idea is the singleton pattern, however.
Singleton is nice pattern to use but it has its own disadvantages. Do read following blogs by Miško Hevery before using singletons.
Singletons are Pathological Liars
Root Cause of Singletons
Where Have All the Singletons Gone?
the Singleton pattern is what you're looking for.
I prefer to allow a singleton but not enforce it so in never hide the constructors and destructors. That had already been said just giving my support.
My twist is that I don't use often use a static member function unless I want to create a true singleton and hide the constr. My usual approach is this:
template< typename T >
T& singleton( void )
{
static char buffer[sizeof(T)];
static T* single = new(buffer)T;
return *single;
}
Foo& instance = singleton<Foo>();
Why not use a static instance of T instead of a placement new? The static instance gives the construction order guarantees, but not destruction order. Most objects are destroyed in reverse order of construction, but static and global variables. If you use the static instance version you'll eventually get mysterious/intermittent segfaults etc after the end of main.
This means the the singletons destructor will never be called. However, the process in coming down anyway and the resources will be reclaimed. That's kinda tough one to get used to but trust me there is not a better cross platform solution at the moment. Luckily, C++0x has a made changes to guarantee destruction order that will fix this problem. Once your compiler supports the new standard just upgrade the singleton function to use a static instance.
Also, I in the actual implemenation I use boost to get aligned memory instead of a plain character array, but didn't want complicate the example
The simplest and concurrency safe implementation is Scott Meyer's singleton:
#include <iostream>
class MySingleton {
public:
static MySingleton& Instance() {
static MySingleton singleton;
return singleton;
}
void HelloWorld() { std::cout << "Hello World!\n"; }
};
int main() {
MySingleton::Instance().HelloWorld();
}
See topic IV here for an analysis from John Vlissides (from GoF fame).
Related
I'm looking at two implementations of the Singleton design pattern.
I wanted to know how the second one works, in particular:
Why has the author chosen to return DB as a reference.
Why does the static class object DB in getDatabaseConnection() not need to be defined outside of the SingleDatabase class as such:
SingletonDatabase& SingletonDatabase::DB;
Does a static class object, like a static variable, only get created once (and is shared amongst all objects of the same class)?
Implementation
class SingletonDatabase {
private:
SingletonDatabase() {
std::cout << "Initializing database" << std::endl;
instanceCount++; // Used in testing later on.
}
public:
SingletonDatabase(const SingletonDatabase&) = delete;
SingletonDatabase& operator=(const SingletonDatabase&) = delete;
static SingletonDatabase& getDatabaseConnection() {
static SingletonDatabase DB;
return DB;
}
static int instanceCount;
};
int SingletonDatabase::instanceCount = 0;
I'm used to seeing the implementation with a static pointer, which the author mentioned is not thread safe. He prefers this method.
Thanks!
Why has the author chosen to return DB as a reference.
Instead of a reference, a pointer could have been used as well. The reference expresses better that the pointee is granted to exist. (Return by value instead would have corrupted the concept.)
Why does the static class object DB in getDatabaseConnection() not need to be defined outside of the SingleDatabase class as such:
SingletonDatabase& SingletonDatabase::DB;
It's not a member variable but a static variable with a local scope but the life-time of a static → granted to exist from first access until end of process.
SO: What is the lifetime of a static variable in a C++ function? (a little bit aged but still correct)
This would've been worked the same way in a plain function. That the surrounding function is a (static member function) is not that relevant concerning this.
Does a static class object, like a static variable, only get created once (and is shared amongst all objects of the same class)?
Yes.
To be correct, it's shared between any caller of this function.
Btw. this is known as Meyers Singleton:
FleCSI: Meyer’s Singleton → SO: C++ Singleton design pattern
SO: Is Meyers' implementation of the Singleton pattern thread safe?
To complete #Scheff's points:
I'm used to seeing the implementation with a static pointer, which the
author mentioned is not thread safe. He prefers this method.
As this Q/A shows, implementing the singleton pattern with pointers is not thread-safe.
I just want to know when should I use singleton class over static object and vice versa. Because same can be used to have only one instance.
One reason I can guess about the storage difference in memory.
Is there any other reason to choose one over the other.
The main difference between a singleton and a static object is that the singleton guarantees that there can only be one instance of a particular class type, whereas a static object is only a single instance of a particular type. This means that the fundamental difference is whether it makes sense for the class to have multiple instances or not. For example, let's say that you have a factory that builds widgets.
class WidgetFactory {
public:
int numberOfWidgetsBuiltInTheWholeApplication();
// returns number_of_widgets_built
std::shared_ptr<Widget> build();
// increments number_of_widgets_built
private:
size_t number_of_widgets_built;
};
Let's also assume that we want to guarantee that we can determine the number of Widgets that were created in the entire application, and enforcing that there is only one WidgetFactory is an easy way to do this. This is where we would use a singleton. If we were to just use a static object, like this:
WidgetFactory& theWidgetFactory()
{
static WidgetFactory widget_factory;
return widget_factory;
}
we would have no guarantee that theWidgetFactory().numberOfWidgetsBuiltInTheWholeApplication() was actually the real total, since someone else could come along and make their own WidgetFactory instance.
However, if we make WidgetFactory be a singleton, we now have that guarantee. We could do that perhaps by making the constructors private:
class WidgetFactory {
public:
int numberOfWidgetsBuiltInTheWholeApplication();
std::shared_ptr<Widget> build();
private:
WidgetFactory();
WidgetFactory(const WidgetFactory &); // not implemented
friend WidgetFactory& theWidgetFactory();
};
Now only theWidgetFactory() function is allowed to create the instance. There are other ways that we could make numberOfWidgetsBuiltInTheWholeApplication() function properly without using a singleton, but perhaps in some situations that solution is more complicated or has other downsides.
where only static initialization is involved, a global constant is ok. where dynamic initialization is involved, you want to avoid the static initialization fiasco. hence if you must, singleton should be preferred.
however, mutable singletons are generally just global variables in disguise.
therefore, to the extent practically possible, avoid them.
I'm new to C++ and OOP in general and have been trying to learn efficient or 'correct' ways to do things, but am still having trouble.
I'm creating a DataStore class that holds data for other classes/objects. There will only ever be one instance/object of this class; however, there doesn't really need to be an object/instance since it's global data, right. In this case I feel like it's just a way to provide scope. So, I want to directly change the class members instead of passing around the object. I have read about static and _extern, but I can't decide if either would be viable, or if anything else would be better.
Right now I'm passing the one created object around to change it's data, but I would rather the class be accessed as 'itself' instead of by 'an instance of itself' while still retaining the idea of it being an object.
Typically, this sort of problem (where you need one, but only ever one - and you are SURE you never ever need more), is solved by using a "singleton" pattern.
class Singleton
{
public:
static Singleton* getInstance()
{
if (!instance) instance = new Singleton();
return instance;
}
int getStuff() { return stuff; }
private:
Singleton() { stuff = 42; }
static Singleton *instance;
int stuff;
};
then in some suitiable .cpp file>
static Singleton *instance;
Or use a global variable directly:
class Something
{
public:
Something() { stuff = 42; }
int getStuff() { return stuff; }
private:
int stuff;
}
extern Something global_something; // Make sure everyone can find it.
In ONE .cpp file:
Something global_something;
Since BOTH of these are essentially a global variable solution, I expect someone disliking global variables will downvote it, but if you don't want to pass around your class object everywhere, a global variable is not a terrible idea. You just have to be aware that global variables are not necessarily a great idea as a solution in general. It can be hard to follow what is going on, and it certainly gets messy if you suddenly need more than one (because you decided to change the code to support two different storages, or whatever) - but this applies to a singleton too.
EDIT: In a comment OP explained the data store will be read by code running in multiple threads, and updated by code in one thread. My previous answer no longer applies. Here's a better answer.
Don't use a global variable to hold the store's instance. This will open the door for many subtle bugs that can haunt you for a long while. You should give your reading threads read-only access to the store. Your writing thread should get read-write access.
Make sure your read methods in the data store are properly marked as const. Then create a single instance of the data store, and put a pointer to it in a const global variable. Your writing thread should have another mechanism of getting a non-const pointer (add a GetInstance public static method, as suggested by #Mats).
My previous answer:
If you're certain there will always be just one data store instance, don't pass it around.
Global variables are frowned upon, and some languages (Java and C#) outlawed them altogether. So in C# and Java you use static class members instead, which are practically the same thing (with exactly the same problems).
If you can put your single instance in a a const global variable, you should be fine.
If you're doing any kind of multithreading, you'll need to make sure your store is thread-safe, or else really bad things will happen.
I do this for object that have 1 instance most of time during execution of program.
class Object {
private:
Object();
friend Object & GetObject();
public:
...
};
inline Object & GetObject() {
static Object O;
return O;
}
1) this is less verbose than singleton.
2) this avoid pitfall of global object, such as undefined initialization order.
you can use a controversial Singleton pattern or you can use one of PARAMETERISE FROM ABOVE approaches described in Mark Radford (Overload Journal #57 – Oct 2003) SINGLETON - the anti-pattern! article.
PARAMETERISE FROM ABOVE approach (in his opinion) strengthen encapsulation and ease initialisation difficulties.
The classic lazy evaluated and correctly destroyed singleton:
class S
{
public:
static S& getInstance()
{
static S instance; // Guaranteed to be destroyed.
// Instantiated on first use.
return instance;
}
private:
S() {}; // Constructor? (the {} brackets) are needed here.
// Dont forget to declare these two. You want to make sure they
// are unaccessable otherwise you may accidently get copies of
// your singleton appearing.
S(S const&); // Don't Implement
void operator=(S const&); // Don't implement
};
But note: this is not thread-safe.
see here for good StackOverflow post about Singletons
I would like to discuss the nuances of implementation of well known Singleton design pattern.
Here there are two implementations in C++:
http://www.codeproject.com/Articles/1921/Singleton-Pattern-its-implementation-with-C
and another one is this:
#ifndef __SINGLETON_HPP_
#define __SINGLETON_HPP_
template <class T>
class Singleton
{
public:
static T* Instance() {
if(!m_pInstance) m_pInstance = new T;
assert(m_pInstance !=NULL);
return m_pInstance;
}
protected:
Singleton();
~Singleton();
private:
Singleton(Singleton const&);
Singleton& operator=(Singleton const&);
static T* m_pInstance;
};
template <class T> T* Singleton<T>::m_pInstance=NULL;
#endif
If we compare this versions what advantages and disadvantages does they have and eventually, which version is preferred?
The main differences between these two implementations are:
the first adds a redundant flag to tell you whether or not a pointer is null, and so takes up slightly more memory than it needs to;
the second is not a singleton at all: there is nothing to stop T from having a public constructor, thereby breaking the singleton restriction.
The main problems with both of them (beyond the fact that a singleton is never a good idea in the first place) are:
construction is not thread-safe; calling Instance() from two threads could cause two objects to be created;
both leak memory; they dynamically create the object with new, but never call delete.
In C++, it is very difficult to manage the lifetime of a globally-accessible object safely; for that reason (and many others), I would recommend avoiding the Singleton anti-pattern altogether. Create objects in well-managed scopes, and pass references where needed.
If you really want a globally-accessible instance, then in most cases the simplest and safest option is:
static Singleton & Instance() {
static Singleton instance;
return instance;
}
This will be created the first time the function is called, and a C++11 compiler must ensure that this is thread-safe. The remaining problem is that the instance might be destroyed before other static objects, causing a disaster if their destructors try to access it.
Basically, both implementations are the same. Implementation on CodeProject provides 2 things:
singleton status flag, which allows you to mark singleton as "old" from outside (and then properly reinstantiate it from inside)
getInstance method, which is nothing special from singleton's perspective. However this makes the code way more readable for other persons AND yourself after some time.
Just the difference between
Cat::meow(); and
Cat::getInstance()->meow()
I've got a class (A) that accesses (indirectly via a static method) a static variable (an STL container) in another class (B) in its constructor and destructor.
A objects may be global, global constants, static members of another class, stored in other classes (which may themselves have global or static instances) or basically anywhere else a c++ object can be.
If an A object is constructed before the static members in B or destructed after the static members in B, it will cause a crash at some point (usually an access violation).
Is there some way to guarantee that all instances of class A (except those that have leaked, since by definition there "lost" and so wont be destructed any way) are constructed after and destructed before B's static variable?
I've seen some solutions for making a specific variable be constructed/destructed before/after another, however not a general case of all instances of a given type so am not sure how to approach this.
No. This is known as the static-initialization fiasco. The order that objects get constructed prior to entering main is unspecified. The only guarantee is that it happens.
What you can do is lazy-initialize. This means your objects won't be initialized until you use them. Such as:
struct A { /* some data */ };
struct B { B(void){ /* get A's data */ } };
A& get_A(void)
{
static A instance;
return instance;
}
B& get_B(void)
{
static B instance;
return instance;
}
You use get_A and get_B to get the global instances. The part where B uses A should use get_A, and your use of B should be with get_B. Note the get_B is optional in your case.
What happens when B is first created? (Either globally or in the function) The constructor will call get_A and that's where A will be created. This let's you control the order things get constructed.
Note I think I reversed your A and B.
In general, no such method. There are workarounds, though. You can get an object with global scope and a slightly-less-than global lifetime by having a global pointer and initializing/destructing it in main/WinMain. Also, you place your global state to be destructed last in a ref-counted heap object.
Also, consider redesign :)
The book "Modern C++ Design" covers this issue nicely.
Google Books contains scans of much of it - see section 6.5 (page 135) - link.
You can handle this cleanly, by putting pointers to the objects in global space,
then newing them in the desired order in your main, and destroying them in the desired order at the end of the main.
As others pointed, there is no standard and portable way to solve this problem, due to the Static initialization order fiasco issue.
However, you should be able to solve your problem by applying a bit of design, so you gain a degree of control when (and how) objects of A and B are constructed. Take a look on design patterns like creational pattern Singleton it is considered in many (if not most) cases as anti-pattern, despite it is worth to learn about it. Also look at to Monostate pattern which may be used as a bit better Singleton. These patterns can help to control object creation and lifetime, so things are properly initialized before use.
Generally, it's a good idea to avoid globals - sticking to deglobalisation is a good idea.
In case if you use lazy singletons (that return on-demand created statics) you may end up with possibility where one singleton uses another one after it was already deleted. For example, imagine you have a global HttpClient singleton that allows you to make http requests. Also, you probably want to have logging, which might be provided by Log singleton:
class HttpClient
{
...
static HttpClient& singleton()
{
static HttpClient http;
return http;
}
};
Same for Log singleton. Now, imagine HttpClient constructor and destructor simply log that that HttpClient was created and deleted. In this case destructor of HttpClient may end up using deleted Log singleton.
Sample code:
#include <stdio.h>
class Log
{
Log()
{
msg("Log");
}
~Log()
{
msg("~Log");
}
public:
static Log& singleton()
{
static Log log;
return log;
}
void msg(const char* str)
{
puts(str);
}
};
class HttpClient
{
HttpClient()
{
Log::singleton().msg("HttpClient");
}
~HttpClient()
{
Log::singleton().msg("~HttpClient");
}
public:
static HttpClient& singleton()
{
static HttpClient http;
return http;
}
void request()
{
Log::singleton().msg("HttpClient::request");
}
};
int main()
{
HttpClient::singleton().request();
}
and the output is:
Log
HttpClient
HttpClient::request
~HttpClient
~Log
So far everything is correct, simply because it happened that Log was constructed before HttpClient, which means that HttpClient can still use Log in its destructor. Now simply comment out logging code in HttpClient constructor and you'll end up with this output:
Log
HttpClient::request
~Log
~HttpClient
As you can see, log is being used after its destructor ~Log was already called. As pointed out, deglobalization might be a better approach, but if you want to use on-demand created singletons and make some of them live longer than the others, then you can make such singletons use a global static initialized on demand. I use that approach quite often in production code:
class Log
{
friend std::unique_ptr<Log>::deleter_type;
...
static std::unique_ptr<Log> log;
static Log& createSingleton()
{
assert(!log);
log.reset(new Log);
return *log;
}
public:
static Log& singleton()
{
static Log& log = createSingleton();
return log;
}
};
std::unique_ptr<Log> Log::log;
Now, regardless of order in which these singletons were constructed, destruction order will ensure that Log is destructed after HttpClient. This, however, might still fail and produce unexpected output if HttpClient was used from a global static constructor. Or if you want to have multiple such "super" globals (like Log and Config for example) that use each other in random order, you will still have these problem. In such cases sometimes it's just better allocate once on heap never delete some of these objects.