Limitations

While Boost.Atomic strives to implement the atomic operations from C++11 and later as faithfully as possible, there are a few limitations that cannot be lifted without compiler support:

Using non-POD-classes as template parameter to atomic<T> results in undefined behavior: This means that any class containing a constructor, destructor, virtual methods or access control specifications is not a valid argument in C++98. C++11 relaxes this slightly by allowing "trivial" classes containing only empty constructors. Advise: Use only POD types.
C++98 compilers may transform computation- to control-dependency: Crucially, memory_order_consume only affects computationally-dependent operations, but in general there is nothing preventing a compiler from transforming a computation dependency into a control dependency. A fully compliant C++11 compiler would be forbidden from such a transformation, but in practice most if not all compilers have chosen to promote memory_order_consume to memory_order_acquire instead (see this gcc bug for example). In the current implementation Boost.Atomic follows that trend, but this may change in the future. Advice: In general, avoid memory_order_consume and use memory_order_acquire instead. Use memory_order_consume only in conjunction with pointer values, and only if you can ensure that the compiler cannot speculate and transform these into control dependencies.
Fence operations enforce "too strong" compiler ordering: Semantically, memory_order_acquire/memory_order_consume and memory_order_release need to restrain reordering of memory operations only in one direction. Since there is no way to express this constraint to the compiler, these act as "full compiler barriers" in this implementation. In corner cases this may result in a less efficient code than a C++11 compiler could generate.
No interprocess fallback: using atomic<T> in shared memory only works correctly, if atomic<T>::is_lock_free() == true.