I am sure this could have been answered but I couldn't actually find a consolidated answer.
what are the problems with the following singleton that is just a function and guaranteed to have initialization and assuming T supports operator!, needed constructors, functions etc? (I am not looking for thread safety). More over, its ok for others to create objects of T as T in my case is a database handle I want to use for the life of my program.
template<typename T>
T* getInstance(){
static T instance;
if ( !instance && !instance.initialize() ){
return NULL;
}
else {
return &instance;
}
}
There are some mistakes in your code -- the template type is being used instead of the variable.
For what you need (don't care about thread safety & need it for the entire duration of your application), it might be exactly what you need. You might wish to start from this though:
template<typename T> T* getInstance()
{
static T instance;
return &instance;
}
This won't even compile. Moreover, using singletons will get you in trouble sooner or later. For instance, when will you destroy the instance? In C++ it is generally better to be explicit about construction and destruction. Lookup the static gateway pattern (example in C#).
Good luck!
Related
Now I'm developing a c++ project. And I don't know what's a good way of c++ Factory's create method. My environment is below.
Environment:
gcc 4.8.2 g++
built with std=c++11 option
I've created a Item class its instances are created by MyFactoryClass.
class Item {
public:
void hoge();
private:
int fuga;
string foo;
};
In this case, what's a good way to implement create method? In general later method is good, but I've heard RVO in recent c++. So do both ways are no problems? And if there are better ways, I'd love to hear your examples.
static Item createItem(int id);
static void createItem(int id, Item& item);
Returning the objects is fine:
static Item createItem(int id);
You're right that RVO can help, and it usually does, but even if in some case the optimiser didn't achieve TVO, it may fall back on move semantics which can still be acceptible. For example, given a std::string implementation supporting move semantics, the foo member will be initialised by moving rather than copy construction.
All up, returning by value is the more commonly recommended and used practice these days. It also means the caller doesn't to construct an object beforehand, which might be problematic if there's no appropriate constructor to create an object in a not-ready-for-use state (and when you can avoid giving classes constructors that leave them in such states, it encourages good localised RAII style).
NOTE: I am trusting that you do indeed want a factory as requested in the question, and do not actually want to use the factory method pattern to create instances of different types, albeit all derived from a common base.
If you want to create just an object then you may use following generic way which can be used for any class:
template<typename Class, typename... Args>
Class Create (Args&&... args)
{
return Class(args...); // RVO takes place here
}
Above is just an example, you may always modify it according to requirement. Demo.
Usage:
MyClass myClass = Create<MyClass>(Arg1, Arg2, Arg3);
However, this method is actually a wrapper upon constructor.
I think you should return a pointer to the Item
class MyFactoryClass final
{
public:
static Item* create( const int aId );
private:
MyFactoryClass();
};
or use a shared pointer.
std::shared_ptr< Item > create( const int aId );
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.
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).