Sign in to follow this  
Defend

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

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  

  • Forum Statistics

    • Total Topics
      628283
    • Total Posts
      2981823
  • Similar Content

    • By noodleBowl
      I was wondering if anyone could explain the depth buffer and the depth stencil state comparison function to me as I'm a little confused
      So I have set up a depth stencil state where the DepthFunc is set to D3D11_COMPARISON_LESS, but what am I actually comparing here? What is actually written to the buffer, the pixel that should show up in the front?
      I have these 2 quad faces, a Red Face and a Blue Face. The Blue Face is further away from the Viewer with a Z index value of -100.0f. Where the Red Face is close to the Viewer with a Z index value of 0.0f.
      When DepthFunc is set to D3D11_COMPARISON_LESS the Red Face shows up in front of the Blue Face like it should based on the Z index values. BUT if I change the DepthFunc to D3D11_COMPARISON_LESS_EQUAL the Blue Face shows in front of the Red Face. Which does not make sense to me, I would think that when the function is set to D3D11_COMPARISON_LESS_EQUAL the Red Face would still show up in front of the Blue Face as the Z index for the Red Face is still closer to the viewer
      Am I thinking of this comparison function all wrong?
      Vertex data just in case
      //Vertex date that make up the 2 faces Vertex verts[] = { //Red face Vertex(Vector4(0.0f, 0.0f, 0.0f), Color(1.0f, 0.0f, 0.0f)), Vertex(Vector4(100.0f, 100.0f, 0.0f), Color(1.0f, 0.0f, 0.0f)), Vertex(Vector4(100.0f, 0.0f, 0.0f), Color(1.0f, 0.0f, 0.0f)), Vertex(Vector4(0.0f, 0.0f, 0.0f), Color(1.0f, 0.0f, 0.0f)), Vertex(Vector4(0.0f, 100.0f, 0.0f), Color(1.0f, 0.0f, 0.0f)), Vertex(Vector4(100.0f, 100.0f, 0.0f), Color(1.0f, 0.0f, 0.0f)), //Blue face Vertex(Vector4(0.0f, 0.0f, -100.0f), Color(0.0f, 0.0f, 1.0f)), Vertex(Vector4(100.0f, 100.0f, -100.0f), Color(0.0f, 0.0f, 1.0f)), Vertex(Vector4(100.0f, 0.0f, -100.0f), Color(0.0f, 0.0f, 1.0f)), Vertex(Vector4(0.0f, 0.0f, -100.0f), Color(0.0f, 0.0f, 1.0f)), Vertex(Vector4(0.0f, 100.0f, -100.0f), Color(0.0f, 0.0f, 1.0f)), Vertex(Vector4(100.0f, 100.0f, -100.0f), Color(0.0f, 0.0f, 1.0f)), };  
    • By Rannion
      Hi,
      I'm trying to fill a win64 Console with ASCII char.
      At the moment I have 2 solutions: one using std::cout for each line, let's say 30 lines at once using std::endl at the end of each one.
      The second solution is using FillConsoleOutputCharacter. This method seems a lot more robust and with less flickering. But I'm guessing, internally it's using a different table than the one used by std::cout. I'm trying to fill the console with the unsigned char 0xB0 which is a sort of grey square when I use std::cout but when using FillConsoleOutputCharacter it is outputted as the UTF8 char '°'.
      I tried using SetConsoleOutputCP before but could not find a proper way to force it to only use the non-extended ASCII code page...
      Has anyone a hint on this one?
      Cheers!
    • By Vortez
      Hi guys, i know this is stupid but i've been trying to convert this block of asm code in c++ for an hour or two and im stuck
      ////////////////////////////////////////////////////////////////////////////////////////////// /////// This routine write the value returned by GetProcAddress() at the address p /////////// ////////////////////////////////////////////////////////////////////////////////////////////// bool SetProcAddress(HINSTANCE dll, void *p, char *name) { UINT *res = (UINT*)ptr; void *f = GetProcAddress(dll, name); if(!f) return false; _asm { push ebx push edx mov ebx, f mov edx, p mov [ebx], edx // <--- put edx at the address pointed by ebx pop edx pop ebx } return res != 0; } ... // ie: SetProcAddress(hDll, &some_function, "function_name"); I tried:
      memcmp(p, f, sizeof(p)); and UINT *i1 = (*UINT)p; UINT *i2 = (*UINT)f; *f = *p; The first one dosent seem to give the right retult, and the second one won't compile.
      Any idea?
    • By adapelin
      I am a computer engineering student and i have the assignment below. İ only can write the 2D maze array and have no idea about creating car and time as well. Could anyone write and explain hot to do???
      Minimum Criteria: You are expected to design the game by using C ++ . Below are the minimal criteria: • You must create game board with 2 - Dimensional Matrix • Bonuses create with randomly in the game board • All bonuses have got the same value but different effect for car and score . These effects may be positive or negative . • You must use pointer for creating and using car . Some bonuses may be change car type. • When the game finish, you must show high - score. • For moving car , you need to create coordinate s randomly and you need to write proper control statements. • You must use functions for drawing game board and changing car type . If you need extra functions, you can use it. • If you cannot get out the maze when the time is up , the game is over and you need to show high score. In this project, you must do all minimum criteria. In the end, your program must be work without any errors. Bonus: • Save and load high score information to/from disk • Each bonus has got different random values. • You can create cheat codes for the game. • You can create alternative control for car . • Car can jump over the wall but may lose the score . When car exit the maze , game is over and you need to show high score.    
    • By Angelic Ice
      Hey everyone!
      Text is down below, just wanted to provide some C++ish pseudo-code to help me expressing my issue ('...' defines omitted details):
      class Interface_Tree { public: ... } class Tree : public Interface_Tree { public: ... private: std::vector<Interface_Bucket> buckets; } class Interface_Bucket { public: ... add_object(Interface_Object* obj) } class Special_Bucket : public Interface_Bucket { public: add_object(Interface_Bucket_Object* obj) { /* If `Interface_Bucket_Object` cannot be cast to `Special_Bucket_Object_Category`, do nothing. This would require a dynamic_cast which I want to avoid, that probably cannot unless restructuring. Check what enum-type `Special_Bucket_Object_Category` If `VERY_IMPORTANT` use pointer `very_important_obj`. Else add to `objs`. */ } private: std::vector<Interface_Bucket_Object*> objs; Interface_Bucket_Object* very_important_obj; } class Interface_Bucket_Object { public: ... } enum Special_Bucket_Object_Category { IMPORTANT, VERY_IMPORTANT, SPAM }; class Special_Bucket_Object : public Interface { public: ... private: Special_Bucket_Object_Category category; } I wanted to start programming to interfaces (or in C++, virtual classes) instead of actual classes (which are now just derived ones) in order to improve unit-testing etc., hence every class derives a base, that can be easily implemented differently.
      But the issue is, if I have a Hash-Bucket data-structure class owning buckets that collect bucket-objects, how can the bucket differentiate characteristics of an implementation of the implemented bucket-object? Sure, I can do a dynamic-cast, if that fails just abort, but I do not want to do a dynamic-cast, because I would rather restructure my code.
      I want my bucket-objects to have a flag (could also be called tag, category, ...) that notifies a bucket that this object needs the entire bucket, hence the enum in my code expressing the flags an object can raise.
      If I would omit all interface-stuff, it would be fairly easy. My Bucket's add_object() method could easily only be called with that exact object and since the exact bucket-object type is now given, and not just some interface, accessing the enum is trivial via a getter-method.
      And a last reminder: I'm not using virtual-classes to profit from inheritance in a sense of a bucket being able to collect a tons of different implementations, just one implementation that carries an enum. The bucket-tree won't own different types of buckets neither, just one implementation kind of bucket. The only reason I use inheritance is to enable easy unit-testing.
      So, how can I access the object's category without dynamic-casting?
       
       
  • Popular Now