On Saturday 23 November 2013 12:37:43 tim wrote:
hi andrey,
hmmm, i see your points ... however in a way, i'd prefer if this functionality could be built upon boost.atomic, mainly to keep API compatibility with std::atomics.
I suppose, the extensions could be made just as functions. What I don't like about this approach is the need to cast pointers to atomic<> to pointers to the underlying integers. We have a few places in Boost.Sync with such code and it really bothers me. Do you think we could at least add a method to get the pointer or reference to the internal storage inside atomic<>?
yes, this sounds reasonable ...
Resurrecting this discussion... I gave some thought to this and implementing the operations just as functions and not as atomic<> members seems clunky. Users will reasonably ask why they are not part of the atomic<> interface. Using atomic<> members on some cases and free functions in other looks odd and inconvenient. So far I can see 3 alternatives: 1. Just add new members to atomic<> and document them as extensions. Personally, I'd go with this one. 2. Same as #1 but make an option to disable these extensions at compile time (e.g. through a config macro). This will have negative consequences with Boost.Sync because it will require these extensions and won't compile without them. 3. Leave atomic<> with the standard interface and add its equivalent but with extensions. My favorite name is nuclear<>. :) With the new Boost.Atomic design it shouldn't cause much code duplication, although it'll be difficult to document why there are two similar components in the library. But it's my second preference. What do you think?