Singleton implementation: Is a namespace approach often preferable over a singleton class?

Question

(This questions assumes that a global + unique object is the goal. I would like to clarify that this does not mean it is asking about or advocating the if/why/when of using/not-using singletons or globals.)

I am wondering if there's a technicality about C++ that I'm missing, so my question is:

Is a namespace implementation of the singleton pattern in C++ valid? And if so, is there a reason why it is not often suggested as the better approach?

From Google's style guidelines, we see namespace non-member functions recommended over static member function, but only when not sharing static data:

"Rather than creating classes only to group static member functions which do not share static data, use namespaces instead."

Why shy away from letting non-member functions share static data, declared in an unnamed namespace? Is there something wrong about this that explains why namespaces aren't generally suggested as a better alternative to writing a singleton class in C++?

Because I can't find recommendations of the namespace approach, but it is very easy to find the class approach despite C++ not enforcing the use of classes:

C++ Singleton design pattern

Can any one provide me a sample of Singleton in c++?

Singleton instance declared as static variable of GetInstance method

http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

Singleton: How should it be used

Using a named namespace with an unnamed namespace in its source file:

• You can have 'state' via static data
• You can gain the extra privacy of putting things in an unnamed namespace
• You can still control the construction order of its static objects by using static pointers, and constructing from function calls.
• You don't need to implement a singleton class

---

Edit - Example of namespace approach I was thinking:

SingleThing.h:

namespace single_thing   // The singleton (if this is actually valid)
{
    void GrowSomeCats(int amount); // Typical setter
    int GetNumCats();              // Typical getter
}

SingleThing.cpp:

#include "Balloon.h"

namespace // Acting like private members and functions
{   
    int numCats = 4;        // POD
    Balloon* wilson = NULL; // Not POD (and not a singleton)

    // Contrived 'private' function
    bool CanGrowCats()      
    { return wilson && wilson->LikesCats(); }

    // Contrived excuse to instantiate non-POD 'members'
    void RandomlyCreateOtherObjects()
    {
        if (!wilson /* && someRandomiserImTooLazyToType()*/ )
            wilson = new Balloon();
    }
}

namespace single_thing  // 'Public' functions
{
    void GrowSomeCats(int amount)
    {
        RandomlyCreateOtherObjects();
        if (CanGrowCats()) 
            numCats += amount;
    }

    GetNumCats()
    { return numCats; }
}

Answer 1

(I assume we can agree that global state is a dangerous thing that has to be used with special care.)

Technically your singleton namespace is equivalent to a singleton class. However it has one major drawback that makes it a no-go in my opinion: It hides the fact that it is stateful. Ever used std::strtok()? Remember what an atrocious mess it is? That’s because it hides its statefulness, too.

Because global state is inherently dangerous, any piece of functionality that uses it should make that fact abundantly clear at the call site, preferrably by using language constructs – because nobody reads comments or documentation. A Foo::instance()->do_work(); is a known pattern that makes it quite clear that something special is going on; a foo::do_work(); does not.

Answer 2

Singleton design pattern is about creation the only instance of a useful class (there is no need in creation of useless objects). In C++ classes are defined with class and struct keywords. To be useful a singleton class, beside creation and destruction, should also implement some methods that operate with the instance. To ensure singularity, a singleton class should hide its constructors and expose a static method for accessing the instance.

Using only namespaces one would not be able to define useful methods of the singleton. Implementing the instance access method as a function in a namespace instead of the class itself is possible, but would require 'friending' that function, and does not make sense because the class is already defined.

Implementing a non-object singleton (e.g. of a plain data type) would assume that the instance does not require construction and thus there is no need for singleton.