Initializing a program using a Singleton

Question

I have read multiple articles about why singletons are bad.
I know it has few uses like logging but what about initalizing and deinitializing.
Are there any problems doing that?
I have a scripting engine that I need to bind on startup to a library.
Libraries don't have main() so what should I use?
Regular functions or a Singleton.
Can this object be copied somehow:

class
{
public:
   static void initialize();
   static void deinitialize();

}  bootstrap;

If not why do people hide the copy ctor, assignment operator and the ctor?

Answer 1

A singleton's purpose is to have only ONE instance of a certain class in your system. The C'tor, D'tor and CC'tor are hidden, in order to have a single access point for receiving the only existing instance.

Usually the instance is static (could be allocated on the heap too) and private, and there's a static method (usually called GetInstance) which returns a reference to this instance.

The question you should ask yourself when deciding whether to have a singleton is : Do I really need to enforce having one object of this class?

There's also the inheritance problem - it can make things complicated if you are planning to inherit from a singleton.

Another problem is How to kill a singleton (the web is filled with articles about this issue)

In some cases it's better to have your private data held statically rather than having a singleton, all depends on the domain.

Note though, that if you're multi-threaded, static variables can give you a pain in the XXX...

So you should analyse your problem carefully before deciding on the design pattern you're going to use...

In your case, I don't think you need a singleton because you want the libraries to be initialized at the beginning, but it has nothing to do with enforcing having only one instance of your class. You could just hold a static flag (static bool Initialized) if all you want is to ensure initializing it only once.

Calling a method once is not reason enough to have a singleton.

Answer 2

It's a good practice to provide an interface for your libraries so that multiple modules (or threads) can use them simultaneously. If you really need to run some code when modules are loaded then use singletons to init parts that must be init once.

Answer 3

Libraries in C++ have a much simpler way to perform initialization and cleanup. It's the exact same way you'd do it for anything else. RAII.

Wrap everything that needs to be initialized in a class, and perform its initialization in the constructor. Voila, problems solved.

All the usual problems with singletons still apply:

• You are going to need more than one instance, even if you hadn't planned for it. If nothing else, you'll want it when unit-testing. Each test should initialize the library from scratch so that it runs in a clean environment. That's hard to do with a singleton approach.
• You're screwed as soon as these singletons start referencing each others. Because the actual initialization order isn't visible, you quickly end up with a bunch of circular references resulting in accessing uninitialized singletons or stack overflows or deadlocks or other fun errors which could have been caught at compile-time if you hadn't been obsessed with making everything global.
• Multithreading. It's usually a bad idea to force all threads to share the same instance of a class, becaus it forces that class to lock and synchronize everything, which costs a lot of performance, and may lead to deadlocks.
• Spaghetti code. You're hiding your code's dependencies every time you use a singleton or a global. It is no longer clear which objects a function depends on, because not all of them are visible as parameters. And because you don't need to add them as parameters, you easily end up adding far more dependencies than necessary. Which is why singletons are almost impossible to remove once you have them.

Answer 4

count the number of singletons in your design, and call this number 's'

count the number of threads in your design, and call this number 't'

now, raise t to the s-th power; this is roughly the number of hairs you are likely to lose while debugging the resulting code.

(I personally have run afoul of code that has over 50 singletons with 10 different threads all racing to get to .getInstance() first)