The One: A Singleton Discussion
by Robin Tan (aka Sobeit Void)
Updated May 1, 2002

Abstract

The singleton is a recurring pattern used by programmers. The singleton pattern is easy to understand but implementation-wise in C++ it has lots of subtle problems. This article discusses those problems.

The reader is assumed to have a basic understanding of the singleton pattern. There are many articles on the subject available on the net. Please read at least one as I assume some knowledge of singletons.

Should there be an error, bug me at robin@cyberversion.com

Why singletons?

For starters, let's examine why we need singletons. Take a look at this program.

// main.cpp
#include <iostream>
using namespace   std;

extern int x;

class C
{
public:
  C()
  {
    // may not print 3
    cout << x << "\n";
  }
};

C c;

int   main()
{
  return   0;
}

// another.cpp
int F()
{
  return 3;
}

int x = F();

Whether the above program prints 3 or 0 becomes dependent on the order in which you link main.cpp and another.cpp. Switch them around and you get different results.

Initialization of static objects is well defined with each translation unit (ie. .cpp file), but not across multiple files. This is why we need singletons.

Meyer's Singleton

This solution was first proposed by Scott Meyer. It often goes in the form below.

class MyClass
{
  MyClass()   {}
  ~MyClass()  {}

  // undefined
  MyClass( const MyClass & );
  MyClass& operator=( MyClass );

public:

  static   MyClass& Get_Instance()
  {
    static   MyClass  instance;
    return   instance;
  }
};

The ctor (constructor), dtor (destructor), copy ctor and assignment operator are defined privately to avoid unauthorized creation.

This simple solution works by having a local static variable inside a function. The variable is initialized the first time Get_Instance() is called and deallocated when main exits.

It is an elegant solution that fulfils what many programmers need from a singleton.

But..

Meyer's singleton is not without problems. Some immediate problems are

By storing an auto object (one that is allocated on the stack), we cannot store derived classes.
The order of destruction is undefined.

No problem, we store a local pointer instead of local instance. This would allow Get_Instance() to return a reference to its parent interface (perhaps an abstract interface).

// class MyChild : public Parent
      
static   Parent&  MyChild::Get_Instance()
{
  static   Parent *p = new MyChild();
  return   *p;
}

Problem 1 is solved, except that the singleton now leaks because the destructor is never called. The obvious solution here then would be to store a local static smart pointer (like std::auto_ptr) instead of the raw pointer.

Now that the first problem is taken care of, let's look at the second.

Meyer's singleton is initialized when Get_Instance() is first called. We solved the initialization order problem but another problem remains - the order of destruction.

A static variable inside a function is registered by at_exit(), and is deallocated when main exits. We have no control over when it gets called or when the destructors of global objects call the singleon - it may be already deallocated! To prove my point, try this wicked sample that is designed break Meyer's singleton.

Notice the order of calls produced. After main exits, the singleton is deallocated yet another call to Get_Instance() is made afterwards. For this simple class it probably wouldn't crash, but if your class has data members, it means those members won't be available anymore.

This occurs because we are relying on the compiler to automatically register the deallocation using at_exit(). If we store a pointer instance, we could avoid this issue, but then no one would be deallocating it. We either leak, or risk crashing.

It is clear now that Meyer's singleton is insufficient for singletons that needs to be called within destructors of global objects. Granted, such singletons are rare, but what would you do if you faced one?

Note: In case you are wondering about what situations you might need a singleton that has defined order of construction/destruction, think about a global logging system.

Nifty Counter

The nifty counter singleton has a defined order of construction and destruction. This solution to the above problem is described in C++ Faqs. (Not the free online version, the book has more info on it)

We observe that local variables used in functions have an undefined destruction order. Only pointers can choose their destruction time.

In essence, this is how the nifty counter works. Look at the sample before I explain.

A nifty counter class is created to hold a pointer to MyClass. The Get_Instance is removed from MyClass into the nifty counter instead.

Note at the end of MyClass.h, there is a static instance of the nifty counter. Before you scream at the atrocity of declaring variables in headers, calm down and look at how it works.

Every file that includes MyClass.h will have an local instance of the nifty counter. The Nifty counter class stores an reference count of how many instances it was created. Within each translation unit, the order of initialization/destruction is well defined (I said this before). The order of construction/destruction is first in/last out (FILO).

Since we have to include MyClass.h before using the singleton, we are unknowingly creating a local instance of the counter in every translation unit. Since this local counter is always destructed last in the translation unit, the order of destruction is well defined (when no one needs to use it anymore).

Does this come for free? Well almost. Notice we have to create a local counter per translation unit. This means that starting/shutting down the program will take more time because we have to page those sections into memory. If you can live with that, this singleton should serve you well.

Zerob Singleton

This is a bonus for those who have the book Modern C++ Design by Andrei Alexandrescu.

This is a singleton holder inspired by the book. In the book's implementation of singleton holder, it keeps track of the order of destruction using a list. I did not particularly like that way of implementation, so I created this singleton holder instead. It follows the book's implementation closely. However, for the singleton lifetime, I provide a nifty counter and Meyer's singleton policy instead. You probably have to read the book to understand how to use it.

This singleton holder is a part of a free reusable game toolkit (the availability of which will be announced in the near future). I provide it here as I feel it is relevant to this discussion. Take note though, it requires a very compliant C++ compiler.

It currently compiles on Gcc 3.0 and Comeau only. Gcc 2.95, VC++ 6, and VS.Net all fail to compile it (VS.Net can compile with some minor modifications) I haven't tried Borland C++, but I suspect it won't compile it either.

This is one reason why more compilers need to be compliant with the standard. Go pressure your vendors.

Abuse of singletons

Implementing a singleton is fraught with dangers. Singletons provide more safety than using global variables but most of the time, they are still used more often than they should be.

Practical experience suggests than it is often possible to redesign so the singleton becomes a member variable or local static variable. Indeed, this should be a worthy goal to strive for.

Do we really need the graphics renderer to be global? Can it be a member variable of an Application object instead?

Does the factory for creating objects need to be a singleton? Wouldn't it be better if we localize all the creation code in a single module?

Think about the functionality of the class. Is it necessary for it to be a singleton or a mere convenience? For convenience sake, take note of the problems you are generating by having a singleton. A redesign would almost always benefit in the long run.

Always remember to KISS (Keep it simple stupid).

Discuss this article in the forums

Date this article was posted to GameDev.net: 5/24/2002
(Note that this date does not necessarily correspond to the date the article was written)