20 Jul
2011
20 Jul
'11
6:04 p.m.
On Wed, Jul 20, 2011 at 18:51, Tim Blechmann <tim@klingt.org> wrote:
If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted.
That seems unnecessary. Can't Boost.Lockfree simply include (a version of) Boost.Atomic as an implementation detail for now?
this would somehow mean to fork boost.atomic, move everying to a `namespace detail'. might introduce some maintenance overhead to keep it in sync with the original library.
Excuse me if it's common knowledge around here, but I've seen several libraries relying on boost.atomic that have been reviewed, so may I ask : why haven't Boost.Atomic been reviewed yet? It looks like it's already finished and reliable... Joël Lamotte