c++ singleton implementation : pimpl idiom for singletons, pros and cons

Answer 1

Using case A has following benefits:

1. You reduce dependency between classes SingletonClassMembers and SingletonHiddenImpl.
2. You don't need to create configurator pattern in class SingletonClassMembers if you trying avoid restriction on (1) by dependency injection
3. This case is weak, but anyway: it is simple to maintenance single class
4. In multithreading environment you will need to support both class synchronization mechanism, while in single class only single locks is needed.

Answer 2

As you only have one instance of your singleton, you can actually move your helpers into the implementation class as "static" there without requiring them to be private inside the header. Of course you don't want to initialise them until you start your class so you would use some kind of smart-pointer, could be auto_ptr here or boost::scoped_ptr, or a pointer with boost::once initialisation (more thread-safe) with deletes in your singleton's destructor.

You can call this model C and probably has the best of both worlds as you completely hide your implementation.

As is the case with any singleton, you need to be extra careful not to throw in your constructor.

Answer 3

When considering efficiency with pimpl, it is not the heap that causes overhead, but the indirection (done by delegation). This delegation typically isn't optimized out (at least not at the time I was considering this ;-)), so there is not a big gain apart from the startup (1 time) penalty for creating the impl. (BTW, I didn't see any delegation functions in your example)

So I don't see that much difference in using pimpl in normal classes or in singletons. I think in both case, using pimpl for classes with limited interface and heavy implementation, it makes sense.