Imported Upstream version 1.67.0upstream/1.67.0

1 files changed, 63 insertions, 14 deletions

diff --git a/doc/html/atomic/limitations.html b/doc/html/atomic/limitations.html
index f127667b65..dfa9cea02c 100644
--- a/doc/html/atomic/limitations.html
+++ b/doc/html/atomic/limitations.html
@@ -34,15 +34,39 @@
     </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem">
-          <span class="bold"><strong>Using non-POD-classes as template parameter to <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;</span><span class="identifier">T</span><span class="special">&gt;</span></code>
-          results in undefined behavior</strong></span>: 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. <span class="bold"><strong>Advise</strong></span>: Use only POD types.
+          <span class="bold"><strong>Aggregate initialization syntax is not supported</strong></span>:
+          Since <span class="bold"><strong>Boost.Atomic</strong></span> sometimes uses storage
+          type that is different from the value type, the <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;&gt;</span></code> template needs an initialization
+          constructor that performs the necessary conversion. This makes <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;&gt;</span></code>
+          a non-aggregate type and prohibits aggregate initialization syntax (<code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;</span><span class="keyword">int</span><span class="special">&gt;</span> <span class="identifier">a</span> <span class="special">=</span> <span class="special">{</span><span class="number">10</span><span class="special">}</span></code>).
+          <span class="bold"><strong>Boost.Atomic</strong></span> does support direct and unified
+          initialization syntax though. <span class="bold"><strong>Advice</strong></span>:
+          Always use direct initialization (<code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;</span><span class="keyword">int</span><span class="special">&gt;</span> <span class="identifier">a</span><span class="special">(</span><span class="number">10</span><span class="special">)</span></code>)
+          or unified initialization (<code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;</span><span class="keyword">int</span><span class="special">&gt;</span> <span class="identifier">a</span><span class="special">{</span><span class="number">10</span><span class="special">}</span></code>)
+          syntax.
         </li>
 <li class="listitem">
-          <span class="bold"><strong>C++98 compilers may transform computation- to control-dependency</strong></span>:
-          Crucially, <code class="computeroutput"><span class="identifier">memory_order_consume</span></code>
+          <span class="bold"><strong>Initializing constructor is not <code class="computeroutput"><span class="keyword">constexpr</span></code>
+          for some types</strong></span>: For value types other than integral types and
+          <code class="computeroutput"><span class="keyword">bool</span></code>, <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;&gt;</span></code> initializing constructor needs
+          to perform runtime conversion to the storage type. This limitation may
+          be lifted for more categories of types in the future.
+        </li>
+<li class="listitem">
+          <span class="bold"><strong>Default constructor is not trivial in C++03</strong></span>:
+          Because the initializing constructor has to be defined in <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;&gt;</span></code>,
+          the default constructor must also be defined. In C++03 the constructor
+          cannot be defined as defaulted and therefore it is not trivial. In C++11
+          the constructor is defaulted (and trivial, if the default constructor of
+          the value type is). In any case, the default constructor of <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;&gt;</span></code>
+          performs default initialization of the atomic value, as required in C++11.
+          <span class="bold"><strong>Advice</strong></span>: In C++03, do not use <span class="bold"><strong>Boost.Atomic</strong></span> in contexts where trivial default constructor
+          is important (e.g. as a global variable which is required to be statically
+          initialized).
+        </li>
+<li class="listitem">
+          <span class="bold"><strong>C++03 compilers may transform computation dependency
+          to control dependency</strong></span>: Crucially, <code class="computeroutput"><span class="identifier">memory_order_consume</span></code>
           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
@@ -59,22 +83,47 @@
           the compiler cannot speculate and transform these into control dependencies.
         </li>
 <li class="listitem">
-          <span class="bold"><strong>Fence operations enforce "too strong" compiler
-          ordering</strong></span>: Semantically, <code class="computeroutput"><span class="identifier">memory_order_acquire</span></code>/<code class="computeroutput"><span class="identifier">memory_order_consume</span></code> and <code class="computeroutput"><span class="identifier">memory_order_release</span></code> 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.
+          <span class="bold"><strong>Fence operations may enforce "too strong"
+          compiler ordering</strong></span>: Semantically, <code class="computeroutput"><span class="identifier">memory_order_acquire</span></code>/<code class="computeroutput"><span class="identifier">memory_order_consume</span></code> and <code class="computeroutput"><span class="identifier">memory_order_release</span></code> need to restrain
+          reordering of memory operations only in one direction. Since in C++03 there
+          is no way to express this constraint to the compiler, these act as "full
+          compiler barriers" in C++03 implementation. In corner cases this may
+          result in a slightly less efficient code than a C++11 compiler could generate.
+          <span class="bold"><strong>Boost.Atomic</strong></span> will use compiler intrinsics,
+          if possible, to express the proper ordering constraints.
+        </li>
+<li class="listitem">
+          <span class="bold"><strong>Atomic operations may enforce "too strong"
+          memory ordering in debug mode</strong></span>: On some compilers, disabling
+          optimizations makes it impossible to provide memory ordering constraints
+          as compile-time constants to the compiler intrinsics. This causes the compiler
+          to silently ignore the provided constraints and choose the "strongest"
+          memory order (<code class="computeroutput"><span class="identifier">memory_order_seq_cst</span></code>)
+          to generate code. Not only this reduces performance, this may hide bugs
+          in the user's code (e.g. if the user used a wrong memory order constraint,
+          which caused a data race). <span class="bold"><strong>Advice</strong></span>: Always
+          test your code with optimizations enabled.
         </li>
 <li class="listitem">
           <span class="bold"><strong>No interprocess fallback</strong></span>: using <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;</span><span class="identifier">T</span><span class="special">&gt;</span></code>
           in shared memory only works correctly, if <code class="computeroutput"><span class="identifier">atomic</span><span class="special">&lt;</span><span class="identifier">T</span><span class="special">&gt;::</span><span class="identifier">is_lock_free</span><span class="special">()</span> <span class="special">==</span> <span class="keyword">true</span></code>.
         </li>
+<li class="listitem">
+          <span class="bold"><strong>Signed integers must use <a href="https://en.wikipedia.org/wiki/Two%27s_complement" target="_top">two's
+          complement</a> representation</strong></span>: <span class="bold"><strong>Boost.Atomic</strong></span>
+          makes this requirement in order to implement conversions between signed
+          and unsigned integers internally. C++11 requires all atomic arithmetic
+          operations on integers to be well defined according to two's complement
+          arithmetics, which means that Boost.Atomic has to operate on unsigned integers
+          internally to avoid undefined behavior that results from signed integer
+          overflows. Platforms with other signed integer representations are not
+          supported.
+        </li>
 </ul></div>
 </div>
 <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
 <td align="left"></td>
-<td align="right"><div class="copyright-footer">Copyright &#169; 2011 Helge Bahmann<br>Copyright &#169; 2012 Tim Blechmann<br>Copyright &#169; 2013, 2017 Andrey Semashev<p>
+<td align="right"><div class="copyright-footer">Copyright &#169; 2011 Helge Bahmann<br>Copyright &#169; 2012 Tim Blechmann<br>Copyright &#169; 2013, 2017, 2018 Andrey Semashev<p>
         Distributed under the Boost Software License, Version 1.0. (See accompanying
         file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)
       </p>