Singleton pattern in C++

You should probably read up Alexandrescu’s book.

Regarding the local static, I haven’t use Visual Studio for a while, but when compiling with Visual Studio 2003, there was one local static allocated per DLL… talk about a nightmare of debugging, I’ll remember that one for a while :/

1. Lifetime of a Singleton

The main issue about singletons is the lifetime management.

If you ever try to use the object, you need to be alive and kicking. The problem thus come from both the initialization and destruction, which is a common issue in C++ with globals.

The initialization is usually the easiest thing to correct. As both methods suggest, it’s simple enough to initialize on first use.

The destruction is a bit more delicate. global variables are destroyed in the reverse order in which they were created. So in the local static case, you don’t actually control things….

2. Local static

struct A
{
  A() { B::Instance(); C::Instance().call(); }
};

struct B
{
  ~B() { C::Instance().call(); }
  static B& Instance() { static B MI; return MI; }
};

struct C
{
  static C& Instance() { static C MI; return MI; }
  void call() {}
};

A globalA;

What’s the problem here ? Let’s check on the order in which the constructors and destructors are called.

First, the construction phase:

• A globalA; is executed, A::A() is called
• A::A() calls B::B()
• A::A() calls C::C()

It works fine, because we initialize B and C instances on first access.

Second, the destruction phase:

• C::~C() is called because it was the last constructed of the 3
• B::~B() is called… oups, it attempts to access C‘s instance !

We thus have undefined behavior at destruction, hum…

3. The new strategy

The idea here is simple. global built-ins are initialized before the other globals, so your pointer will be set to 0 before any of the code you’ve written will get called, it ensures that the test:

S& S::Instance() { if (MInstance == 0) MInstance = new S(); return *MInstance; }

Will actually check whether or not the instance is correct.

However has at been said, there is a memory leak here and worst a destructor that never gets called. The solution exists, and is standardized. It is a call to the atexit function.

The atexit function let you specify an action to execute during the shutdown of the program. With that, we can write a singleton alright:

// in s.hpp
class S
{
public:
  static S& Instance(); // already defined

private:
  static void CleanUp();

  S(); // later, because that's where the work takes place
  ~S() { /* anything ? */ }

  // not copyable
  S(S const&);
  S& operator=(S const&);

  static S* MInstance;
};

// in s.cpp
S* S::MInstance = 0;

S::S() { atexit(&CleanUp); }

S::CleanUp() { delete MInstance; MInstance = 0; } // Note the = 0 bit!!!

First, let’s learn more about atexit. The signature is int atexit(void (*function)(void));, ie it accepts a pointer to a function that takes nothing as argument and returns nothing either.

Second, how does it work ? Well, exactly like the previous use case: at initialization it builds up a stack of the pointers to function to call and at destruction it empties the stack one item at a time. So, in effect, the functions get called in a Last-In First-Out fashion.

What happens here then ?

• Construction on first access (initialization is fine), I register the CleanUp method for exit time

• Exit time: the CleanUp method gets called. It destroys the object (thus we can effectively do work in the destructor) and reset the pointer to 0 to signal it.

What happens if (like in the example with A, B and C) I call upon the instance of an already destroyed object ? Well, in this case, since I set back the pointer to 0 I’ll rebuild a temporary singleton and the cycle begins anew. It won’t live for long though since I am depiling my stack.

Alexandrescu called it the Phoenix Singleton as it resurrects from its ashes if it’s needed after it got destroyed.

Another alternative is to have a static flag and set it to destroyed during the clean up and let the user know it didn’t get an instance of the singleton, for example by returning a null pointer. The only issue I have with returning a pointer (or reference) is that you’d better hope nobody’s stupid enough to call delete on it :/

4. The Monoid Pattern

Since we are talking about Singleton I think it’s time to introduce the Monoid Pattern. In essence, it can be seen as a degenerated case of the Flyweight pattern, or a use of Proxy over Singleton.

The Monoid pattern is simple: all instances of the class share a common state.

I’ll take the opportunity to expose the not-Phoenix implementation 🙂

class Monoid
{
public:
  void foo() { if (State* i = Instance()) i->foo(); }
  void bar() { if (State* i = Instance()) i->bar(); }

private:
  struct State {};

  static State* Instance();
  static void CleanUp();

  static bool MDestroyed;
  static State* MInstance;
};

// .cpp
bool Monoid::MDestroyed = false;
State* Monoid::MInstance = 0;

State* Monoid::Instance()
{
  if (!MDestroyed && !MInstance)
  {
    MInstance = new State();
    atexit(&CleanUp);
  }
  return MInstance;
}

void Monoid::CleanUp()
{
  delete MInstance;
  MInstance = 0;
  MDestroyed = true;
}

What’s the benefit ? It hides the fact that the state is shared, it hides the Singleton.

• If you ever need to have 2 distinct states, it’s possible that you’ll manage to do it without changing every line of code that used it (replacing the Singleton by a call to a Factory for example)
• Nodoby’s going to call delete on your singleton’s instance, so you really manage the state and prevent accidents… you can’t do much against malicious users anyway!
• You control the access to the singleton, so in case it’s called after it’s been destroyed you can handle it correctly (do nothing, log, etc…)

5. Last word

As complete as this may seem, I’d like to point out that I have happily skimmed any multithread issues… read Alexandrescu’s Modern C++ to learn more!