Gavin Lambert via Boost Unordered's concurrent flat map
Which is where, exactly? It does not appear to currently exist in the library as far as I can tell, not even in develop...
I apologize for forgetting this. It lives here: https://github.com/boostorg/unordered/tree/feature/cfoa There's also an open PR for this, if you'd like to offer some code review: https://github.com/boostorg/unordered/pull/188
Andrey Semashev via Boost There is a better implementation in Boost.Atomic:
Well, I'm always up for that!
I would rather have those, along with a spin_mutex implementation, in Boost.Thread, but I realize Peter wouldn't want to depend on it in Boost.SmartPtr.
I wouldn't like this either. Right now, SmartPtr is a header-only library and adding a dependency on Thread introduces a binary dependency which means `./vcpkg install boost-smart-ptr` now creates the `libboost_thread.a`. This applies similarly for Unordered as well. I'd prefer to avoid having a binary dependency _just_ for a small header-only component.
That everyone depends on Core doesn't mean we should pile everything in it.
I agree with this, which is why I figured I'd ask the mailing list. Do enough other Boost developers agree that these primitives are universal enough such that they should be in Core? If not, that's fine. There's always vendoring. After all, a little copy-paste is better than a little dependency or sayeth the great Rob Pike. But purporting that we agree they should be somewhere in Boost (and not in a detail header), where should they live? - Christian