• Advertisement
Sign in to follow this  

C++ What can't a namespace do that a singleton does?

Recommended Posts

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++?

Edited by Defend

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

They're equivalent so it doesn't really matter what you pick. Global functions that share hidden static state of extremely common in C. I guess singletons are more common in C++ as they're OOish. 

Fighting for a better singleton is like hoping to step in a better dog turd though... :D

Share this post


Link to post
Share on other sites

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. :D 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Let's look at what the C++ standard library does, since it was developed by experts over many years and had extreme use testing over decades in real-world scenarios.

The C++ standard library offers singletons (ie. hidden variables of static storage duration accessed only by static member functions like std::locale::global()).

The C++ standard library offers "global" variables (ie. visible variables of static storage duration at namespace level) and associated namespace-level functions (eg. std::cout) to operate on them.

The choice of which is used is based on two criteria.  The first is ease of use.  The standard IO streams are used frequently, are well-known, and there's no point beating about the bush they're "global variables."  Imagine if they were "singletons" instead.

std::cout.get_instance() << "Hello World!" << std::cout::endl();

My guess is printf() using its hidden globals and complete type erasure would still be the only in-use method of output if that were the case.

The second, and probably more important, is the strictly-specified lifetime requirements of the "global variables" in the library.  They need to exist before any user code is called and can not get destroyed until after the last user code has executed.  It turns out that's a little bit easier to do with 1970s-era linkage machinery if you use global variables instead of a C++ function (although not with any modern linkers).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
21 hours ago, Defend said:

Any search (I can find anyway) related to 'how to singleton'  and C++ produces the class approach

Because that's what a singleton is, by definition -- a class that can only be instantiated once. If you don't have a class then it's not a singleton.

Of course though this is functionally equivalent to a bunch of global functions that share some hidden global state... which pre-dates the word "singleton" by decades. The word "singleton" was invented to specifically describe the pattern of using a class to implement the idea of global functions with hidden global state.

The "singleton" pattern is a very specific way of implementing hidden global state. Not every implementation of hidden global state is a singleton.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
On 10/21/2017 at 8:24 AM, Bregma said:

The C++ standard library offers "global" variables (ie. visible variables of static storage duration at namespace level) and associated namespace-level functions (eg. std::cout) to operate on them.

The choice of which is used is based on two criteria.  The first is ease of use.  The standard IO streams are used frequently, are well-known, and there's no point beating about the bush they're "global variables."  Imagine if they were "singletons" instead.


std::cout.get_instance() << "Hello World!" << std::cout::endl();

 

std::cout isn't a function, it's an object—an instance of std::ostream<char>. It's made globally available by being declared extern at namespace scope in the ostream header. Also, std::endl isn't a member function, but rather a global- (err, namespace-) scope function that takes a std::ostream instance as its sole parameter (it's a manipulator, technically).

In effect, the C++ standard library uses globally-available instances without restricting your ability to create more instances of the same type. The problem with singletons is the commingling of "I only need one" with type-enforced "there can be only one." (Maybe we should call them Highlander types? :-P ) An interesting pattern that exists in Apple's Cocoa libraries is for a class to offer a static sharedInstance() method that yields the same underlying instance, but not prevent you from creating additional instances, even when they abstract over, say, the user filesystem (NSFileManager).

Quote

The second, and probably more important, is the strictly-specified lifetime requirements of the "global variables" in the library.  They need to exist before any user code is called and can not get destroyed until after the last user code has executed.  It turns out that's a little bit easier to do with 1970s-era linkage machinery if you use global variables instead of a C++ function (although not with any modern linkers).

Items with the extern storage class specifier have external linkage. External linkage cannot be used in a definition of an automatic storage duration object, in effect yielding static or thread duration. This really isn't a problem for global availability.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By Ward Correll
      I include the source code from what I am playing with. It's an exercise from Frank Luna's DirectX 12 book about rendering a skull from a text file. I get a stack overflow error and the program quits. I don't know where I went wrong it's messy programming on the parts I added but maybe one of you masterminds can tell me where I went wrong.
      Chapter_7_Drawing_in_Direct3D_Part_II.zip
    • By mister345
      Hi guys, so I have about 200 files isolated in their own folder [physics code] in my Visual Studio project that I never touch. They might as well be a separate library, I just keep em as source files in case I need to look at them or step through them, but I will never actually edit them, so there's no need to ever build them.
      However, when I need to rebuild the entire solution because I changed the other files, all of these 200 files get rebuilt too and it takes a really long time.
      If I click on their properties -> exclude from build, then rebuild, it's no good because then all the previous built objects get deleted automatically, so the build will fail.
      So how do I make the built versions of the 200+ files in the physics directory stay where they are so I never have to rebuild them, but
      do a normal rebuild for everything else? Any easy answers to this? The simpler the better, as I am a noob at Visual Studio settings. Thanks.
    • By Snaked
      Im working in this project for 1 year .... mostly i develop a tool and databases for make the different maps and now i'm doing the client for play the game
      Tell me if you like it......
      this is a capture of how is viewing atm

       
       
      https://youtu.be/9251v4wDTQ0
    • By reenigne
      For those that don't know me. I am the individual who's two videos are listed here under setup for https://wiki.libsdl.org/Tutorials
      I also run grhmedia.com where I host the projects and code for the tutorials I have online.
      Recently, I received a notice from youtube they will be implementing their new policy in protecting video content as of which I won't be monetized till I meat there required number of viewers and views each month.

      Frankly, I'm pretty sick of youtube. I put up a video and someone else learns from it and puts up another video and because of the way youtube does their placement they end up with more views.
      Even guys that clearly post false information such as one individual who said GLEW 2.0 was broken because he didn't know how to compile it. He in short didn't know how to modify the script he used because he didn't understand make files and how the requirements of the compiler and library changes needed some different flags.

      At the end of the month when they implement this I will take down the content and host on my own server purely and it will be a paid system and or patreon. 

      I get my videos may be a bit dry, I generally figure people are there to learn how to do something and I rather not waste their time. 
      I used to also help people for free even those coming from the other videos. That won't be the case any more. I used to just take anyone emails and work with them my email is posted on the site.

      I don't expect to get the required number of subscribers in that time or increased views. Even if I did well it wouldn't take care of each reoccurring month.
      I figure this is simpler and I don't plan on putting some sort of exorbitant fee for a monthly subscription or the like.
      I was thinking on the lines of a few dollars 1,2, and 3 and the larger subscription gets you assistance with the content in the tutorials if needed that month.
      Maybe another fee if it is related but not directly in the content. 
      The fees would serve to cut down on the number of people who ask for help and maybe encourage some of the people to actually pay attention to what is said rather than do their own thing. That actually turns out to be 90% of the issues. I spent 6 hours helping one individual last week I must have asked him 20 times did you do exactly like I said in the video even pointed directly to the section. When he finally sent me a copy of the what he entered I knew then and there he had not. I circled it and I pointed out that wasn't what I said to do in the video. I didn't tell him what was wrong and how I knew that way he would go back and actually follow what it said to do. He then reported it worked. Yea, no kidding following directions works. But hey isn't alone and well its part of the learning process.

      So the point of this isn't to be a gripe session. I'm just looking for a bit of feed back. Do you think the fees are unreasonable?
      Should I keep the youtube channel and do just the fees with patreon or do you think locking the content to my site and require a subscription is an idea.

      I'm just looking at the fact it is unrealistic to think youtube/google will actually get stuff right or that youtube viewers will actually bother to start looking for more accurate videos. 
    • By mister345
      Hi, can someone please explain why this is giving an assertion EyePosition!=0 exception?
       
      _lightBufferVS->viewMatrix = DirectX::XMMatrixLookAtLH(XMLoadFloat3(&_lightBufferVS->position), XMLoadFloat3(&_lookAt), XMLoadFloat3(&up));
      It looks like DirectX doesnt want the 2nd parameter to be a zero vector in the assertion, but I passed in a zero vector with this exact same code in another program and it ran just fine. (Here is the version of the code that worked - note XMLoadFloat3(&m_lookAt) parameter value is (0,0,0) at runtime - I debugged it - but it throws no exceptions.
          m_viewMatrix = DirectX::XMMatrixLookAtLH(XMLoadFloat3(&m_position), XMLoadFloat3(&m_lookAt), XMLoadFloat3(&up)); Here is the repo for the broken code (See LightClass) https://github.com/mister51213/DirectX11Engine/blob/master/DirectX11Engine/LightClass.cpp
      and here is the repo with the alternative version of the code that is working with a value of (0,0,0) for the second parameter.
      https://github.com/mister51213/DX11Port_SoftShadows/blob/master/Engine/lightclass.cpp
  • Advertisement