Not asking about singletons here (nor advocating). With that clarified:

If we assume someone wants a global + unique object, why isn't a namespace always the preferred approach in C++, over implementing a singleton class?

I've only seen the namespace approach encouraged when there aren't statics being shared. Eg; from Google's style guidelines:

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

But why not have non-member functions that share static data, declared in an unnamed namespace? And why isn't this generally suggested as a better alternative to writing a singleton class in C++?

This the functional equivalent to having a static variable with a bunch of functions to act on it, which is what you might do in C, and in fact that sort of thing is everywhere in a lot of C codebases.

If anything, the singleton-as-object approach seems marginally better because you can take the type, and therefore pass it into functions as an argument, which lets you more easily refactor later.  Not that either is a terribly great choice.

I'm guessing the reason you don't see them is because you don't see many varieties of code.

6 hours ago, Defend said:

I've only seen the namespace approach encouraged when there aren't statics being shared.

This is because static objects are almost always the wrong choice.

That's not referring to static constants, where the compiler will typically use the value directly to simplify the executed code.  Outside of that use, a static value or a global value is nearly always a bug or design defect.  Usually in the handful of cases where they are useful they still are not ideal from a conceptual standpoint, but instead they are an informed decision where the developers decide the advantage in their specific situation is worth the added cognitive effort of adding the shared state.

6 hours ago, Defend said:

If we assume someone wants a global + unique object, why isn't a namespace always the preferred approach in C++, over implementing a singleton class?

I've never heard an argument that it wasn't, apart from the fact that globals and shared state tend to be 'evil'.

A globally accessed pointer, or perhaps a restricted access pointer with static linkage, can work fine with this scenario, assuming rules are followed to ensure consistency and access through safe patterns.

Imagine a logging framework providing a bunch of functions that take an optional logger. It can have a pointer to an instance that is the default instance, and that default instance can be swapped out. Then a set of freestanding functions can call that instance.

Thus you have functions that exist on an object allowing you to use your own: mylog->Info("This happened (%d)",thing.id);

And you have the namespace-wrapped versions using the default:  logger::Info("This happened (%d)",thing.id);  That version can use a namespace-constrained pointer, perhaps logger::defaultInstance or something, and the free-floating Info function could pass the call directly on to the defaultInstance version if the pointer is valid.

This in turn makes the tradeoff as mentioned above, the implementer decided the convenience was more important that the extra hidden dependency and the burden of ensuring validity of that hidden dependency.  There must be assurances that the defaultInstance pointer has a sane value and is only swapped out at well-defined times.

7 hours ago, Defend said:

And why isn't this generally suggested as a better alternative to writing a singleton class in C++?

Because you still have a static variable, you still have a shared mutable state.  That should be avoided in general, so it makes for a bad suggestion.  It is less bad that other bad practices, but that doesn't make it a good practice.

Shared mutable state brings with it a host of issues.  It can change behind your back, at any time, for reasons you cannot predict.  The risk can be reduced through human-enforced rules about how and when it is used, what the values must be at certain times, but ultimately there can be no enforcement.  In any non-trivial application this will eventually bite you as someone somewhere changes the value.

In addition to being unable to create more than one, the Singleton pattern also frequently invokes shared mutable state among its assorted issues. Since this isn't supposed to be people bashing on Singletons since we all know the pattern is seriously flawed, that's probably enough there.

Frob, I too haven't heard an argument that the namespace  approach is worse (or not) than the class approach, but that's because it is practically impossible to find discussion on that particular question at all. Any search (I can find anyway) related to 'how to singleton'  and C++ produces the class approach. Any search with the word 'singleton' at all results in replies all too keen to launch into thoughts on the pattern and/or globals. I don't disagree with them at all, but they drown the focus on any related specific questions such as this one.

Thank you all though for confirming for me that I'm not just missing something obvious in C++. I think Hodgman's suspicion is a good one. Seraph, your comment  was something I hadn't thought of so that feels like I've finally I found some closure! Many thanks.  

1 hour ago, Defend said:

 

I can think of a way in which using a singleton might be better than a namespace.  Imagine you have a system that you're going to make into a singleton (or namespace).  With a namespace anyone can access anything at any time.  But, now imagine that I want to verify that this system only gets accessed from my main thread.  With a singleton I can have a GetSystem() function that returns the pointer to the system, but I can also add code in there to verify that it's being called from the main thread.   Considering that engines often use singletons for things like a rendering manager, and you also often want that only accessible from a single thread, this would benefit for the singleton pattern.

As mentioned by @SeraphLance, the type-based implementation allows code to easily opt-out of depending on global state, ignore the "baked-in" multiplicity of the type's implementation, and accept precisely the number of instances it wants as dependencies. You can also do this without classes, but in the absence of an aggregating agent such an interface would be awkward and cumbersome (AOS vs SOA). A class will also allow you to utilize other type-driven language functionality like templates and overload resolution, although I doubt this is actually useful or advantageous when it comes to singletons. Perhaps a singleton class is also easier to refactor in the future, but once again still begs the question of why you'd start with one in the first place.

Otherwise, there's nothing functional that you can do with one approach that you can't do with the other. Likewise, there aren't any pitfalls that you would avoid by using one approach over the other.

It's also worth mentioning that namespaces aren't really relevant to the subject, as they're just tools for labeling and organizing code.

23 hours ago, Defend said:

Frob, I too haven't heard an argument that the namespace  approach is worse (or not) than the class approach, but that's because it is practically impossible to find discussion on that particular question at all

That is because as others point out, it is syntactic sugar over the same issue.

The issue is mutable shared states.  Mixing mutable shared state in any sufficiently large system is going to face issues with it.  Two threads are going to modify it, or unrelated systems will fight over it, or similar. They introduce hidden coupling, introduce hidden dependencies, complicate or break tools like dependency injection, block extension, and cause many other issues.

The Singleton pattern (which means there can be only one) is that issue and more. In addition to shared mutable state it also creates unrealistic and improbable demands that a single instance is the only one that will ever be wanted, that no code will ever want to replace it, or extend the behavior, or replace the behavior, or provide either alternate or missing behavior, or many other conditions besides.  It is well-covered as being "evil".

As for the shared mutable states in C and C++, there are a few that cannot be removed. They are holdovers from decades ago (probably long before you were born) when parallel processing was rare. There are the global streams (stdin, stdout, stderr) and their associated global locale; they have c++ class equivalents but they remain the three streams.  These cannot be designed out of the language nor is there a good way to remove them universally, so they are here to stay.

Some shared mutable states remain because removing them would break too much code, but they have alternates for new code to use. There are strerror(), strtok(), and asctime() functions that all have static buffers internally. There are a few oldcharacter conversion functions between multibyte and wide characters that have shared state, such as wctomb(), mbtowc(), wcsrtomb(), and mbsrtowc(). There are some math functions like the gamma() family and rand() family that rely on internal state.  All of these have alternate versions available that do not rely on shared mutable state.

And a few historically were shared but have been corrected, such as the errno codes from system libraries. In some cases there were rather extensive system library changes to support it, but the change was still made.  

There are some on hardware as well.  Floating point control is often fought-over between libraries.  Setting the precision, denormalization options, error handling, and floating point exception resolution are commonly troublesome.  Floating point rounding modes (even/nearest, up, down, and toward zero) can also lead to some 'gotcha' bugs. 

23 hours ago, Defend said:

Thank you all though for confirming for me that I'm not just missing something obvious in C++.

This is common to all languages. You can mask it in various ways, including hiding in namespaces or wrapping on functions that modify hidden variables, but ultimately the underlying problem remains.  

Even in functional languages, where there is tremendous effort made by the language designers to avoid stateful conditions in general, can still occasionally be stung by unintended shared mutable state.

As programs get larger and systems grow they will nearly always have some mutable shared states since there are times when the engineering effort required to avoid it is greater than the project is willing to bear, but that should be weighed as an intentional choice to implement the shared state, and mitigated through policies such as ensuring modification only happens at specific times, or by specific systems, or in specific manners. 

These rules can be put in place in many ways, including having functions that modify a static variable that is kept out of visible scope (such as within an anonymous namespace or as a static variable within a file) but they remain an implementation of a shared mutable state.