On 01/26/18 18:20, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
But my point is that optimizations like these are generally unreliable, and if you really want to have the best possible code then you should better write it in a way so the compiler has less opportunity to screw up.
If we adopt this philosophy, shouldn't there be `opaque_` and `_and_test` increments and decrements, too? `lock inc [r]` instead of `lock add [r], 1`, or even `mov eax, 1; lock add [r], eax` if the compiler can't be trusted to optimize, which we assume.
To some extent, I'm already doing this: https://github.com/boostorg/atomic/blob/develop/include/boost/atomic/detail/... In general though, there has to be a reasonable balance between the library usability and efficiency. I think the current interface is quite close to it.