Singleton class - Which method - c++

Question

I have implemented two methods of how I think a Singleton class should be implemented, I just want the opinion of programmers to which one is the best method to use.
Each of the methods uses these classes:
class Animal {
public:
virtual void speak() const = 0;
};
class Dog {
virtual void speak() { cout << "Woof!!"; }
};
First method:
class AnimalFactory {
public:
static Animal* CreateInstance(int theTypeOfAnimal);
private:
AnimalFactory() { };
static int count; // this will be used to count the number of objects created
static int maxCount; // this is the max count allowed.
};
int AnimalFactory::count = 0;
int AnimalFactory::maxCount = 1;
Animal* AnimalFactory::CreateInstance(int theTypeOfAnimal)
{
Animal* pAnimal = NULL;
if(pAnimal != NULL)
{
return pAnimal;
}
switch(theTypeOfAnimal)
{
case 0:
pAnimal = new Dog();
count++;
break;
case 1:
pAnimal = new Cat();
count++;
break;
case 2:
pAnimal = new Spider();
count++;
break;
default:
cout << "Not known option";
}
return pAnimal;
}
Second Method:
template<typename classType>
class Singleton {
public:
classType& instance()
{
static classType object;
return object;
}
};
Any opinion would be grateful, thanks :)!

Answer 1

In the majority of the cases, Singleton is abused. The general advice is: Don't use it! If you think you really have a case where a Singleton is the correct solution: Probability is still against you. If you are really, really sure you need to use a Singleton, you probably still want to use it as some sort of glorified data: don't. It is gonna hurt you.
OK, you have been warned.
The second approach has the distinct advantage with C++ 2011 that it i thread safe. It also happens to be simpler.
If you are stuck with a compiler not, yet, implementing the C++ 2011 logic and you use your Singleton in a multi-threaded application, you'll need to make sure that it only gets initialized once even if the access function is called concurrently from two threads. Of course, this leads to something else which doesn't work: Do not use the double-checked locking pattern. It [also] doesn't work. If you implemented so that it works, someone will come along and "fix" your code.

Answer 2

Anyway, in embedded environment, you don't need singleton pattern, you don't even need new or malloc.
It's hard to explain, but I try.
Embedded systems must work. There is no IT department armed with manuals and FAQs and internet forums, nobody will tune your Linux system, nobody will fix your config, nobody will install a larger hard disk or memory according to task's needs. Your program can't write a detailed message to stderr and exit() with meaningful error code, if it can, it just means that your embedded system does not work. If you can flash a red led on error, it's better than nothing, but it's still means: device failed.
I think, it's a good practice not to use malloc/free and new/delete. You should "pre-allocate" possible maximum number of objects by defining them as static arrays. Or, if the maximum number of items depends on a configuration which the user can change, you should allocate the fixed number of objects just as program starts, so low memory issue turns out on startup, not half an hour later.
Yes, lot of memory will be wasted, but there will be no mysterious errors. And you have not to deal with memory issues in your program (only at startup).

Answer 3

The first code snippet fails to implement a singleton because AnimalFactory::CreateInstance fails to check the instance count that it maintains.
The second code snippet,
template<typename classType>
class Singleton {
public:
classType& instance()
{
static classType object;
return object;
}
};
when done properly, is called a Meyers' singleton, after Scott Meyers.
The code as given would work but yields awkward usage. To avoid having to instantiate Singleton, the instance method should be declared static. Also, the requirement on classType classes that they should only instantiable by Singleton, should be documented, e.g. as a comment with an example.
Others have already warned you against using singletons, but let me also do that.
Singletons have their uses, such as ensuring that e.g. a Windows API "window class" is only created once, but mainly they're abused as global-variables-in-disguise. One problem with global variables, namely that you don't know when a global variable has been initialized (in C++ programming known as the static initialization order fiasco), is avoided by singletons. However, the main problem, that they serve as spaghetti communication systems, routing chaos-inducing information in untraceable ways between places you would never suspect, is still there.
So, don't.
But if you at some time find that you absolutely need singletons, e.g. for a logging facility, then please do read up on the discussion of singletons in Andrei Alexandrescu's "Modern C++ Design", and then get hold of the Loki library and let it do the job for you.

Answer 4

It looks like you could spare yourself a whole heap of headache by just making a function:
Animal * CreateAnimal(int theTypeOfAnimal)
{
static int count = 0;
static int maxCount = 1;
switch(theTypeOfAnimal)
{
// ...
}
}

Answer 5

Well, the first one doesn't work:
Animal* pAnimal = NULL;
if(pAnimal != NULL)
{
return pAnimal;
}
Do you expect the condition to ever hold?
I've seen the second one before, so I'll go ahead and say it's more idiomatic, at least for this type of singleton, which isn't really a singleton per-say because you have multiple instances, albeit one-per-actual-type. Well, the general idea is okay (for a singleton), but I'd go with something like:
template<typename classType>
class AnimalManager {
public:
static Animal& instance()
{
static classType object;
return object;
}
};
which you could call
Animal& animal = AnimalManager<Dog>::instance();
//assuming you derive Dog from Animal, which you're currently not

Answer 6

I will be downwoted by masses of the Java programmers, but I don't mind: If you know, that your program needs exactly one object instance, feel free to create a global object and write a static get() method which returns (the reference to) it (and don't reference to the global object from elsewhere).
I think, singleton pattern in Java is a technique to implement the global object, in C++ is a technique to hide the global object. But why, it's just as ugly when hidden, as ugly as it's not hidden.
You should also wrap it carefully, in order to make it appear on the scene as other normal objects, and handle it as normal objects. Maybe, later, as the program evolves, there will be more instances of them, and you'll be happy that it already acts as a normal object.

Answer 7

The first solution has some odd coding (see Luchian Grigore answer). Ignoring that:
It is some mix of concepts between a factory and a singleton.
A factory normally is a singleton but what it emits normally is not.
The second one does ensure that you can only create one object of a class, but only iff you wrap it in the Singleton template. If the class has a public constructor, you can create it outside the scheme and thus break the rules.
In my book neither of these is a good way to do a singleton.
To expand a bit: The idea of the singleton is to because you need to manage some specific thing and you need one component to be wholly responsible.
With your first version you can have multiple factories that each create one animal. Doesn't make sense in the real world, doesn't make sense in code.
Your second example tries to allow every call to (optionally) be a singleton - but not all classes need to be, and many will not necessarily behave when "singletonized".

Answer 8

In review, John Vlisides said if one 'pattern' shouldn't have made it into his GOF book it was the singleton. However, also see his discussion of implementing it in C++.
See also Andrei Alexandrescu who explores singletons with 3 different creation models, 4 different lifetime models and 2 threading models, that's 24 ways of implementing a singleton.
Personally, I go out of my way to avoid them by only passing around objects that are needed. It makes testing easier, makes interfaces explicit, etc. You've been warned, of course you've been warned, but will you listen?