Tobias Schwinger wrote:
I'm thinking about a text with some simple code snippets for "here's how to basically use it", "you might use multiple inheritance to make some existing class a singleton", and "you might use non-public inheritance to create a purely static interface".
Along with small tests and demos please. Very cool ideas which would never have occurred to me as I've been too focused on an expedient rather than clever solution.
Well, my implementation has been uploaded just a few weeks ago. Anyway we might as well just request formal review - and, as the crowdedness has lightened, it won't take that long, especially if you volunteer to manage that review ;-).
I'm biased because I need something RIGHT NOW. Of course that's not true but it turns out I started out addressing the issues that the serialization library currently has with multi-threading and dynamic loading/unloading of DLLS. So if I don't have it now, I lose my whole train of thought.
AFAICT, our "lightweight toolbox" is still insufficient to implement a thread-safe Singleton - I might be missing something, though. How would you initialize 'lightweight_mutex' when you can't know that ctors are run in static context (as within a shared library)?
Maybe it's possible to make 'detail::atomic_count' an aggregate and provide a macro for initialization (just as pthread does for its synchronization primitives). Then it would be trivial to implement a 'lightweight_once' on top of it...
Please start thinking about this. I don't see why this can't be a header only library. Of course in my case, the expanded headers (instantiated code) will be compiled into the serializatoin library as an implementation detail. I would much prefer that to having to link in another library. Robert Ramey