What are the reasons for preferring Singleton or function scope local static objects over one another?

Question

Both Marshall Clines' "C++ FAQ Lite" and Scott Meyers' Effective C++ suggest using functions returning local static objects to avoid possible problems with non-local static object initialization order.

In short (from "Effective C++", 3rd edition by Scott Meyers):

FileSystem& tfs()
{
  static FileSystem fs;
  return fs;
}

Both writers add that this is similar to the Singleton pattern, except that this does not ensure that the local fs is the only instance of a FileSystem.

Now, in a situation where one instance of resource-managing class T is enough, what would be your reasons to prefer a Singleton class or this local static approach over one another? It is not strictly necessary to limit using the class T to just one instance, although our application does not need more than one.

Obviously having a global object is an issue when doing TDD, but in this case both approaches are global.

Answer 1

You can use both:

class Singleton {

   public:

      static Singleton & Instance() {
          static Singleton s;
          return s;
      }

   private:

       Singleton() {}
};

Now the only way a Singleton can be created is via the Instance function (because the constructor is private) and so you can guarantee only one Singleton exists. If you want to use the free function approach described in your question, you could consider making the function a friend of the Singleton class while retaining the private constructor.

Note that this construct (as with all constructs that involve static variables) is not thread safe. If thread safety is an issue, you need to consider using something like the double-checked locking pattern when accessing the static Singleton variable.

Answer 2

A Singleton is used when you cannot have more than one object say a CEO class -- obviously two or more CEOs are going to wreck your company;) For a Singleton, you cannot create any more than one object by definition

• private ctor
• static accessor.

However, function scope local objects are a different beast altogether. This idiom does not preclude the possibility of having other such objects around. This is often found in case of Logger classes where you can create your own Logger objects and the library writer also provides you with a DefaultLogger() function for quick and ugly logging which just wraps over a static Logger object.

Note that some implementations of a Singleton object accessor can use the function scope variable idiom.