One of the best talks I have seen. I have contemplated large refactoring of Singleton riddled code. To make it testable. The singletons might be there because it makes sense. There only needs to be one. There should be a global cache of something etc. This talk gives way forward. It gives you hope that it is possible and within a reasonable effort, as Peter also describes.

At about 19:00, the solution given to not wanting vtables is using std::function. That's actually *worse* if you care about vtables, because if you care about vtables you probably care about the performance implications and debuggability of virtual dispatch/function pointers in general, and now to make matters worse you have a potential heap allocation if you give the function a capturing callable that is larger than the small block optimization of std::function for your particular compiler! function_ref is better, but doesn't actually address the concerns that some people have regarding virtual.

All this for slightly easier testability? What if you have thousands of callers of sendData? Are all of them (and/or their stack parents) expected to create instances of the wrappers? What if the DB singleton has a pool of connections (for perf / throttling reasons)? Do people actually use this pattern in real-life? I highly doubt it, at most they'll end up just exporting getDefaultComm and pass that in to get rid of the deprecation warning.

I agree with your implementation: template static T &getInstance() { static T singleton; return singleton; } But, how unique is a static variable in your project (eg. in a web server)? One compiler switch could cause loading a library twice for two "Singleton" instances. You do not need to recognize it in large projects.

It seems that it would not work particularly well. Say I have 1000s functions in 10 layers of 25 years old code, the lowest 3 layers calls original singleton. If we want to pass wrapper around we have to add it to each and every function and if we have three wrappers we have to pass three wrappers around to each and every function too. Any attempt to do initialization on the first use will have problems with threads and there is not much difference with the original singleton. It seems that correct way to do it: (a) define an abstract singleton and derive the real singleton clients will use abstract interface, (b) auto link real singletons into a static initialization list, (c) initialize singletons on the list early in the program lifetime before starting the second thread, (d) for testing derive another singleton from the same base, initialize it in setup function and delete it in tear-down function and use it while in test case -- this is it.