C++11: A generic singleton

http://enki-tech.blogspot.fr/2012/08/c11-generic-singleton.html

by vjeux • 14 years ago

25 32 14 years ago

enki-tech.blogspot.fr

vjeux• 14 years ago

Nice use of perfect forwarding!

vadeo• 14 years ago

Cool article

btilly• 14 years ago

This is interesting.

But be aware that singletons are to be regarded cautiously for all of the reasons that, say, global variables are.

klodolph• 14 years ago

Plus some additional reasons: if a singleton is initialized on first use, it might be hard to reason about which kind of environment exists when it is initialized -- what locks are held, etc.

quotemstr3• 14 years ago

No no no no no. This approach still needs heap allocation, and you still need to chase a pointer for every access to your singleton. That's silly. There's a much better way. Here it is, roughly speaking.

  template<typename T>
  struct singleton_bss {
      T& get() {
          return * ((T*) &this->buffer[0]);
      }
  
      void init(T&& value) {
          new ( (T*) &this->buffer[0] ) T(std::forward<T>  (value));
      }
    
      union {
          char buffer[sizeof(T)];
          long align; // adjust to taste
      };
  };

  singleton_bss<mything> g_thing;

This approach has the huge advantage of not doing any heap allocation. The storage for g_thing lives directly in bss, the portion of your processes' address space initialized by the operating system. g_thing.init() cannot fail if T's constructor is non-throwing --- singleton_bss allocates no memory!

Access to g_thing is much more efficient than access to a typical singleton. There's no pointer-to-the-instance stored in the singleton, so there's no pointer chasing. Access to g_thing is exactly as efficient as access to a plain global variable, which is as efficient as variable access can be.

You can trivially construct a version of singleton_bss that does lazy initialization, takes multiple parameters, destroys the object on module unload, and so on.

keveman2• 14 years ago

Here is the C++11 way of specifying alignment :

    alignas(T) char buffer[sizeof(T)];

Or better still, just use the unrestricted union feature :

    union {
      T t;
    };

Just use &t in place of buffer.

quotemstr3• 14 years ago

Thanks for the tip --- alignas slipped my mind. The compiler I use for most of my work doesn't yet support alignas (or unrestricted unions). I believe a VC++-specific equivalent would for the former trick would be __declspec(align(__alignof(T))).

zerohp• 14 years ago

I prefer the answer given here:

http://stackoverflow.com/questions/1463707/c-singleton-vs-gl...

pfedor2• 14 years ago

This is wrong for reasons given here: http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

pmelendez6• 14 years ago

I am not sure if that applies here... Static objects introduce hard to find bugs because you can't figure out the order of instantiation... Over here there is just one unique instance so you know exactly where it was instantiated.

02f39nrca• 14 years ago

Experience shows the singleton pattern is more trouble than it's worth. Explicitly initialise shared resources in one thread either from main, or if you're writing a shared library, the explicit initialisation function you'll have to add anyway if the library is properly designed.

RomP• 14 years ago

one word: synchronization

skrebbel• 14 years ago

Hooray, now you can use anti-patterns in a generic way!

I have yet to find a single good reason for having singletons, other than dealing with legacy code that has them (and, potentially, logging). Singletons are the worst anti-pattern out there, removing any sense of testability and reconfiguration in your project.

The only good-ish argument for singletons (other than, again, dealing with legacy code that has them) is that inversion of control requires so many objects to be passed around to constructors. This argument becomes invalid once you realise that many-instances-needed-on-constructors is in fact a warning sign that your classes are getting too tightly bound. Draw out the entities again and see where you can abstract or generalize.

pmelendez6• 14 years ago

"I have yet to find a single good reason for having singletons, other than dealing with legacy code that has them (and, potentially, logging). Singletons are the worst anti-pattern out there, removing any sense of testability and reconfiguration in your project"

I think you are being a bit dogmatic here. There are good uses for singleton classes in single threaded applications that don't use unit tests (i.e most mobile games). People should just think and evaluate each case instead or tagging stuff as pattern or anti-pattern. Am I the only one who think that both (pattern and anti-pattern) are evil? This reminds me a lot all the goto controversy.

malkia4• 14 years ago

By this logic anything is acceptable.

enki423• 14 years ago

Hi everyone! I'm the author of this blog.

I agree with most of you that Singleton can lead to destroy a design. I just think that we should not ban something globally, and I'm sure that this (anti-?)pattern can be useful sometimes.

The aim of this post was not to encourage people to use Singleton, but to show how C++11 can improve our way to write classical code. I just took a simple example of singleton.

malkia4• 14 years ago

A global variable is more useful than singleton, since it comes with no battery, plan or pretense.

Singleton at minimal requires thread-safety, and that comes very hard. It also contradicts with itself when a singleton is made thread-specific variable (TLS) - because it's singleton / thread, but not per process.

enki423• 14 years ago

Why should a Singleton be thread safe? Nothing says that it will be used in a multi-threaded environment... For me a Singleton must fulfill the specification given by the Gang of Four.

I'm not saying that it should not be thought thread safe, I just say that it's not the point here.

quotemstr3• 14 years ago

> A global variable is more useful than singleton, since it comes with no battery, plan or pretense.

Initialization and deinitialization of globals in C++ is a trainwreck. A singleton wrapper like the one I proposed upthread gives you deterministic initialization order and doesn't impose a runtime performance penalty.

> Singleton at minimal requires thread-safety

Both Windows and POSIX have locks that can be statically initialized. In Windows,

  SRWLOCK g_thing_lock = SRWLOCK_INIT;

With pthreads,

  pthread_mutex_t g_thing_lock = PTHREAD_MUTEX_INITIALIZER;

Now you can serialize access to your singleton without having to do any explicit and delicate lock initialization. Of course, this isn't the only approach --- you can make the singleton itself threadsafe and have your generic singleton wrapper serialize initialization using a similar approach. TIMTOWTDI.

shanemhansen2• 14 years ago

I have a lot of respect for those C++ guys/girls.

Frankly, If I had to think this hard to get my code written, I wouldn't be writing very much of it. Thank heavens for small languages that leave my brain cycles to think about solving other problems.

But don't listen to me, listen to Linus and Rob Pike.

http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

http://harmful.cat-v.org/software/c++/linus

stephen_g• 14 years ago

Do you mean a small language such as C? Because I disagree completely.

Whenever I use C, I always seem to find myself wishing for C++'s string class, the STL containers and exception handling... There are libraries for C to get containers and things but C interfaces tend to be uglier (in my opinion) and it's annoying to have to use a lot of 3rd party stuff to get things that come with C++.

Just because C++ has a ton of other features (many of which are pretty easy to use incorrectly if you don't know how) doesn't mean you have to use all of them.

shanemhansen2• 14 years ago

C is small and beautiful, but my preference is more along the lines of go, or maybe objective-c or d.

C++11: A generic singleton

Related Stories