Question

When I look for informations about the singleton pattern for C++, I always find examples like this:

class Singleton
{
    public:
        ~Singleton() {
        }

        static Singleton* getInstance()
        {
            if(instance == NULL) {
                instance = new Singleton();
            }
            return instance;
        }

    protected:
        Singleton() {
        }

    private:
        static Singleton* instance;
};

Singleton* Singleton::instance = NULL;

But this kind of singleton also seems to work as well:

class Singleton
{
    public:
        ~Singleton() {
        }

        static Singleton* getInstance()
        {
            return &instance;
        }

    protected:
        Singleton() {
        }

    private:
        static Singleton instance;
};

Singleton Singleton::instance;

I guess that the second singleton is instantiated at the beginning of the program, unlike the first, but is it the only difference?

Why do we find mainly the first?

Answer 1

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14

The static initialization order fiasco is a very subtle and commonly
misunderstood aspect of C++. Unfortunately it’s very hard to detect —
the errors often occur before main() begins.

In short, suppose you have two static objects x and y which exist in
separate source files, say x.cpp and y.cpp. Suppose further that the
initialization for the y object (typically the y object’s constructor)
calls some method on the x object.

That’s it. It’s that simple.

The tragedy is that you have a 50%-50% chance of dying. If the
compilation unit for x.cpp happens to get initialized first, all is
well. But if the compilation unit for y.cpp get initialized first,
then y’s initialization will get run before x’s initialization, and
you’re toast. E.g., y’s constructor could call a method on the x
object, yet the x object hasn’t yet been constructed.

The first method you listed avoids this problem completely. It’s called the “construct on first use idiom”

The downside of this approach is that the object is never destructed.
There is another technique that answers this concern, but it needs to
be used with care since it creates the possibility of another (equally
nasty) problem.

Note: The static initialization order fiasco can also, in some cases,
apply to built-in/intrinsic types.