|
Boost : |
From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-21 16:43:03
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk