Update C++17 library status tables
* doc/xml/manual/status_cxx2017.xml: Document P0024R2 status. * doc/html/*: Regenerate. From-SVN: r270559
This commit is contained in:
Jonathan Wakely
Jonathan Wakely
parent
f90b16c429
commit
7c3e085e44
@ -1,5 +1,8 @@
|
||||
2019-04-24 Jonathan Wakely <jwakely@redhat.com>
|
||||
|
||||
* doc/xml/manual/status_cxx2017.xml: Document P0024R2 status.
|
||||
* doc/html/*: Regenerate.
|
||||
|
||||
* include/bits/fs_path.h (operator<, operator<=, operator>)
|
||||
(operator>=, operator==, operator!=): Make hidden friends, as per
|
||||
LWG 3065.
|
||||
|
||||
@ -70,7 +70,7 @@
|
||||
Program crashes when using library code in a
|
||||
dynamically-loaded library
|
||||
</a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
|
||||
“Memory leaks” in containers
|
||||
“Memory leaks” in libstdc++
|
||||
</a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
|
||||
list::size() is O(n)!
|
||||
</a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
|
||||
@ -593,7 +593,7 @@
|
||||
Program crashes when using library code in a
|
||||
dynamically-loaded library
|
||||
</a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
|
||||
“Memory leaks” in containers
|
||||
“Memory leaks” in libstdc++
|
||||
</a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
|
||||
list::size() is O(n)!
|
||||
</a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
|
||||
@ -708,15 +708,27 @@
|
||||
Link the executable:<br />
|
||||
<span class="command"><strong>g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</strong></span><br />
|
||||
</p></div></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.memory_leaks"></a><a id="q-memory_leaks"></a><p><strong>6.7.</strong></p></td><td align="left" valign="top"><p>
|
||||
<span class="quote">“<span class="quote">Memory leaks</span>”</span> in containers
|
||||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
|
||||
A few people have reported that the standard containers appear
|
||||
<span class="quote">“<span class="quote">Memory leaks</span>”</span> in libstdc++
|
||||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><p>
|
||||
Since GCC 5.1.0, libstdc++ automatically allocates a pool
|
||||
of a few dozen kilobytes on startup. This pool is used to ensure it's
|
||||
possible to throw exceptions (such as <code class="classname">bad_alloc</code>)
|
||||
even when <code class="code">malloc</code> is unable to allocate any more memory.
|
||||
With some versions of <a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>
|
||||
this pool will be shown as "still reachable" when the process exits, e.g.
|
||||
<code class="code">still reachable: 72,704 bytes in 1 blocks</code>.
|
||||
This memory is not a leak, because it's still in use by libstdc++,
|
||||
and the memory will be returned to the OS when the process exits.
|
||||
Later versions of <span class="command"><strong>valgrind</strong></span> know how to free this
|
||||
pool as the process exits, and so won't show any "still reachable" memory.
|
||||
</p><p>
|
||||
In the past, a few people reported that the standard containers appear
|
||||
to leak memory when tested with memory checkers such as
|
||||
<a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>.
|
||||
Under some (non-default) configurations the library's allocators keep
|
||||
free memory in a
|
||||
pool for later reuse, rather than returning it to the OS. Although
|
||||
this memory is always reachable by the library and is never
|
||||
pool for later reuse, rather than deallocating it with <code class="code">delete</code>
|
||||
Although this memory is always reachable by the library and is never
|
||||
lost, memory debugging tools can report it as a leak. If you
|
||||
want to test the library for memory leaks please read
|
||||
<a class="link" href="manual/debug.html#debug.memory" title="Memory Leak Hunting">Tips for memory leak hunting</a>
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -28,11 +28,12 @@ Removal of <code class="filename"><ext/tree></code>, moved to <code class=
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_320"></a><code class="constant">3.2</code></h3></div></div></div><p>
|
||||
</p><p>Symbol versioning introduced for shared library.</p><p>Removal of include <code class="filename"><backward/strstream.h></code>.</p><p>Allocator changes. Change <code class="code">__malloc_alloc</code> to <code class="code">malloc_allocator</code> and <code class="code">__new_alloc</code> to <code class="code">new_allocator</code>. </p><p> For GCC releases from 2.95 through the 3.1 series, defining
|
||||
<code class="literal">__USE_MALLOC</code> on the gcc command line would change the
|
||||
default allocation strategy to instead use <code class="code"> malloc</code> and
|
||||
<code class="function">free</code>. For the 3.2 and 3.3 release series the same
|
||||
default allocation strategy to instead use <code class="code">malloc</code> and
|
||||
<code class="code">free</code>. For the 3.2 and 3.3 release series the same
|
||||
functionality was spelled <code class="literal">_GLIBCXX_FORCE_NEW</code>. From
|
||||
GCC 3.4 onwards the functionality is enabled by setting
|
||||
<code class="literal">GLIBCXX_FORCE_NEW</code> in the environment, see
|
||||
GCC 3.4 onwards the default allocator uses <code class="code">new</code> anyway,
|
||||
but for the optional pooling allocators the functionality is enabled by
|
||||
setting <code class="literal">GLIBCXX_FORCE_NEW</code> in the environment, see
|
||||
<a class="link" href="mt_allocator.html" title="Chapter 20. The mt_allocator">the mt allocator chapter</a>
|
||||
for details.
|
||||
</p><p>Error handling in iostreams cleaned up, made consistent. </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_330"></a><code class="constant">3.3</code></h3></div></div></div><p>
|
||||
|
||||
@ -484,8 +484,9 @@ No <code class="code">stream::attach(int fd)</code>
|
||||
stream-constructor.
|
||||
</p><p>
|
||||
An extension is available that implements this.
|
||||
<code class="filename"><ext/stdio_filebuf.h></code> contains a derived class called
|
||||
<a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00074.html" target="_top"><code class="code">__gnu_cxx::stdio_filebuf</code></a>.
|
||||
<code class="filename"><ext/stdio_filebuf.h></code>
|
||||
contains a derived class called
|
||||
<code class="classname">__gnu_cxx::stdio_filebuf</code>.
|
||||
This class can be constructed from a C <code class="code">FILE*</code> or a file
|
||||
descriptor, and provides the <code class="code">fd()</code> function.
|
||||
</p><p>
|
||||
|
||||
@ -53,40 +53,28 @@
|
||||
This quick and dirty approach is often sufficient for quick
|
||||
debugging tasks, when you cannot or don't want to recompile your
|
||||
application to use the <a class="link" href="debug_mode.html" title="Chapter 17. Debug Mode">debug mode</a>.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="debug.memory"></a>Memory Leak Hunting</h3></div></div></div><p>
|
||||
There are various third party memory tracing and debug utilities
|
||||
On many targets GCC supports AddressSanitizer, a fast memory error detector,
|
||||
which is enabled by the <code class="option">-fsanitize=address</code> option.
|
||||
</p><p>
|
||||
There are also various third party memory tracing and debug utilities
|
||||
that can be used to provide detailed memory allocation information
|
||||
about C++ code. An exhaustive list of tools is not going to be
|
||||
attempted, but includes <code class="code">mtrace</code>, <code class="code">valgrind</code>,
|
||||
<code class="code">mudflap</code>, and the non-free commercial product
|
||||
<code class="code">purify</code>. In addition, <code class="code">libcwd</code> has a
|
||||
replacement for the global new and delete operators that can track
|
||||
memory allocation and deallocation and provide useful memory
|
||||
statistics.
|
||||
</p><p>
|
||||
Regardless of the memory debugging tool being used, there is one
|
||||
thing of great importance to keep in mind when debugging C++ code
|
||||
that uses <code class="code">new</code> and <code class="code">delete</code>: there are
|
||||
different kinds of allocation schemes that can be used by <code class="code">
|
||||
std::allocator</code>. For implementation details, see the <a class="link" href="mt_allocator.html" title="Chapter 20. The mt_allocator">mt allocator</a> documentation and
|
||||
look specifically for <code class="code">GLIBCXX_FORCE_NEW</code>.
|
||||
</p><p>
|
||||
In a nutshell, the optional <code class="classname">mt_allocator</code>
|
||||
is a high-performance pool allocator, and can
|
||||
give the mistaken impression that in a suspect executable, memory is
|
||||
being leaked, when in reality the memory "leak" is a pool being used
|
||||
by the library's allocator and is reclaimed after program
|
||||
termination.
|
||||
<code class="code">mudflap</code> (no longer supported since GCC 4.9.0), ElectricFence,
|
||||
and the non-free commercial product <code class="code">purify</code>.
|
||||
In addition, <code class="code">libcwd</code>, jemalloc and TCMalloc have replacements
|
||||
for the global <code class="code">new</code> and <code class="code">delete</code> operators
|
||||
that can track memory allocation and deallocation and provide useful
|
||||
memory statistics.
|
||||
</p><p>
|
||||
For valgrind, there are some specific items to keep in mind. First
|
||||
of all, use a version of valgrind that will work with current GNU
|
||||
C++ tools: the first that can do this is valgrind 1.0.4, but later
|
||||
versions should work at least as well. Second of all, use a
|
||||
completely unoptimized build to avoid confusing valgrind. Third, use
|
||||
GLIBCXX_FORCE_NEW to keep extraneous pool allocation noise from
|
||||
cluttering debug information.
|
||||
versions should work better. Second, using an unoptimized build
|
||||
might avoid confusing valgrind.
|
||||
</p><p>
|
||||
Fourth, it may be necessary to force deallocation in other libraries
|
||||
as well, namely the "C" library. On linux, this can be accomplished
|
||||
Third, it may be necessary to force deallocation in other libraries
|
||||
as well, namely the "C" library. On GNU/Linux, this can be accomplished
|
||||
with the appropriate use of the <code class="code">__cxa_atexit</code> or
|
||||
<code class="code">atexit</code> functions.
|
||||
</p><pre class="programlisting">
|
||||
@ -121,7 +109,29 @@
|
||||
up the runtime environment, library, and test file, might be:
|
||||
</p><pre class="programlisting">
|
||||
valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out
|
||||
</pre></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="debug.races"></a>Data Race Hunting</h3></div></div></div><p>
|
||||
</pre><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="debug.memory.mtalloc"></a>Non-memory leaks in Pool and MT allocators</h4></div></div></div><p>
|
||||
There are different kinds of allocation schemes that can be used by
|
||||
<code class="code">std::allocator</code>. Prior to GCC 3.4.0 the default was to use
|
||||
a pooling allocator, <code class="classname">pool_allocator</code>,
|
||||
which is still available as the optional
|
||||
<code class="classname">__pool_alloc</code> extension.
|
||||
Another optional extension, <code class="classname">__mt_alloc</code>,
|
||||
is a high-performance pool allocator.
|
||||
</p><p>
|
||||
In a suspect executable these pooling allocators can give
|
||||
the mistaken impression that memory is being leaked,
|
||||
when in reality the memory "leak" is a pool being used
|
||||
by the library's allocator and is reclaimed after program
|
||||
termination.
|
||||
</p><p>
|
||||
If you're using memory debugging tools on a program that uses
|
||||
one of these pooling allocators, you can set the environment variable
|
||||
<code class="literal">GLIBCXX_FORCE_NEW</code> to keep extraneous pool allocation
|
||||
noise from cluttering debug information.
|
||||
For more details, see the
|
||||
<a class="link" href="mt_allocator.html" title="Chapter 20. The mt_allocator">mt allocator</a>
|
||||
documentation and look specifically for <code class="code">GLIBCXX_FORCE_NEW</code>.
|
||||
</p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="debug.races"></a>Data Race Hunting</h3></div></div></div><p>
|
||||
All synchronization primitives used in the library internals need to be
|
||||
understood by race detectors so that they do not produce false reports.
|
||||
</p><p>
|
||||
|
||||
@ -44,7 +44,7 @@ a POSIX-like interface.
|
||||
the current host. In libstdc++ implementation files,
|
||||
<bits/gthr.h> is used to select the proper gthreads file.
|
||||
</p><p>Within libstdc++ sources, all calls to underlying thread functionality
|
||||
use this layer. More detail as to the specific interface can be found in the source <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00883_source.html" target="_top">documentation</a>.
|
||||
use this layer. More detail as to the specific interface can be found in the source <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/index.html" target="_top">documentation</a>.
|
||||
</p><p>By design, the gthread layer is interoperable with the types,
|
||||
functions, and usage found in the usual <pthread.h> file,
|
||||
including <code class="code">pthread_t</code>, <code class="code">pthread_once_t</code>, <code class="code">pthread_create</code>,
|
||||
|
||||
@ -34,11 +34,13 @@
|
||||
library cannot track what you do on your own with a file descriptor,
|
||||
so if you perform any I/O directly, don't expect the library to be
|
||||
aware of it.
|
||||
</p></li><li class="listitem"><p>Beginning with 3.1, the extra <code class="code">filebuf</code> constructor and
|
||||
</p></li><li class="listitem"><p>Beginning with 3.1, the extra
|
||||
<code class="classname">basic_filebuf</code> constructor and
|
||||
the <code class="code">fd()</code> function were removed from the standard
|
||||
filebuf. Instead, <code class="code"><ext/stdio_filebuf.h></code> contains
|
||||
a derived class called
|
||||
<a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00074.html" target="_top"><code class="code">__gnu_cxx::stdio_filebuf</code></a>.
|
||||
filebuf. Instead,
|
||||
<code class="filename"><ext/stdio_filebuf.h></code>
|
||||
contains a derived class template called
|
||||
<code class="classname">__gnu_cxx::stdio_filebuf</code>.
|
||||
This class can be constructed from a C <code class="code">FILE*</code> or a file
|
||||
descriptor, and provides the <code class="code">fd()</code> function.
|
||||
</p></li></ul></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_iterators.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_demangling.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 27. Iterators </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 29. Demangling</td></tr></table></div></body></html>
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@ -174,8 +174,8 @@ i. e. it is a singleton. It can be read and written by calling
|
||||
<code class="code">__gnu_parallel::_Settings::set</code>, respectively.
|
||||
Please note that the first call return a const object, so direct manipulation
|
||||
is forbidden.
|
||||
See <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01005.html" target="_top">
|
||||
<code class="filename">settings.h</code></a>
|
||||
See <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/index.html" target="_top">
|
||||
<code class="filename"><parallel/settings.h></code></a>
|
||||
for complete details.
|
||||
</p><p>
|
||||
A small example of tuning the default:
|
||||
|
||||
@ -759,13 +759,14 @@ Feature-testing recommendations for C++</a>.
|
||||
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html" target="_top">
|
||||
P0031R0
|
||||
</a>
|
||||
</td><td align="center"> 7.1 </td><td align="left"><code class="code"> __cpp_lib_array_constexpr >= 201603 </code></td></tr><tr bgcolor="#C8B0B0"><td align="left"> The Parallelism TS Should be Standardized </td><td align="left">
|
||||
</td><td align="center"> 7.1 </td><td align="left"><code class="code"> __cpp_lib_array_constexpr >= 201603 </code></td></tr><tr bgcolor="#B0B0B0"><td align="left"> The Parallelism TS Should be Standardized </td><td align="left">
|
||||
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0024r2.html" target="_top">
|
||||
P0024R2
|
||||
</a>
|
||||
</td><td align="center"> No </td><td align="left"><code class="code"> __has_include(<execution>) </code>,
|
||||
</td><td align="center"> 9.1 </td><td align="left"><code class="code"> __has_include(<execution>) </code>,
|
||||
<code class="code"> __cpp_lib_execution >= 201603 </code>,
|
||||
<code class="code"> __cpp_lib_parallel_algorithm >= 201603 </code>
|
||||
(requires linking with <code class="code">-ltbb</code>, see Note 3)
|
||||
</td></tr><tr><td align="left"> An algorithm to "clamp" a value between a pair of boundary values </td><td align="left">
|
||||
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0025r0.html" target="_top">
|
||||
P0025R0
|
||||
@ -783,7 +784,7 @@ Feature-testing recommendations for C++</a>.
|
||||
P0226R1
|
||||
</a>
|
||||
</td><td align="center"> 7.1 </td><td align="left"><code class="code"> __cpp_lib_math_special_functions >= 201603 </code>
|
||||
(see Note 3)
|
||||
(see Note 4)
|
||||
</td></tr><tr><td align="left">Adopt the File System TS for C++17 </td><td align="left">
|
||||
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r1.html" target="_top">
|
||||
P0218R1
|
||||
@ -846,7 +847,11 @@ Note 2: This feature is supported in older releases but the
|
||||
<code class="code">__cpp_lib</code> macro is not defined to the right value
|
||||
(or not defined at all) until the version shown in parentheses.
|
||||
</p><p>
|
||||
Note 3: The mathematical special functions are enabled in C++17 mode from
|
||||
Note 3: The Parallel Algorithms have an external dependency on Intel TBB 2018
|
||||
or later. If the <code class="filename"><execution></code>
|
||||
header is included then <code class="code">-ltbb</code> must be used to link to TBB.
|
||||
</p><p>
|
||||
Note 4: The mathematical special functions are enabled in C++17 mode from
|
||||
GCC 7.1 onwards. For GCC 6.x or for C++11/C++14 define
|
||||
<code class="code">__STDCPP_WANT_MATH_SPEC_FUNCS__</code> to a non-zero value
|
||||
and test for <code class="code">__STDCPP_MATH_SPEC_FUNCS__ >= 201003L</code>.
|
||||
@ -1245,11 +1250,11 @@ Feature-testing recommendations for C++</a>.
|
||||
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0608r3.html" target="_top">
|
||||
P0608R3
|
||||
</a>
|
||||
</td><td align="center"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left"> <code class="code">visit<R></code>: Explicit Return Type for <code class="code">visit</code> </td><td align="left">
|
||||
</td><td align="center"> </td><td align="left"> </td></tr><tr><td align="left"> <code class="code">visit<R></code>: Explicit Return Type for <code class="code">visit</code> </td><td align="left">
|
||||
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0655r1.pdf" target="_top">
|
||||
P0655R1
|
||||
</a>
|
||||
</td><td align="center"> </td><td align="left"> </td></tr><tr><td align="left"> <code class="code">std::function</code> move constructor should be <code class="code">noexcept</code> </td><td align="left">
|
||||
</td><td align="center"> 9.1 </td><td align="left"> </td></tr><tr><td align="left"> <code class="code">std::function</code> move constructor should be <code class="code">noexcept</code> </td><td align="left">
|
||||
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0771r1.pdf" target="_top">
|
||||
P0771R1
|
||||
</a>
|
||||
|
||||
@ -56,8 +56,8 @@
|
||||
The header <code class="filename">limits</code> defines
|
||||
traits classes to give access to various implementation
|
||||
defined-aspects of the fundamental types. The traits classes --
|
||||
fourteen in total -- are all specializations of the template class
|
||||
<code class="classname">numeric_limits</code>, documented <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00593.html" target="_top">here</a>
|
||||
fourteen in total -- are all specializations of the class template
|
||||
<code class="classname">numeric_limits</code>
|
||||
and defined as follows:
|
||||
</p><pre class="programlisting">
|
||||
template<typename T>
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -633,17 +633,18 @@ Feature-testing recommendations for C++</link>.
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry> The Parallelism TS Should be Standardized </entry>
|
||||
<entry>
|
||||
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0024r2.html">
|
||||
P0024R2
|
||||
</link>
|
||||
</entry>
|
||||
<entry align="center"> No </entry>
|
||||
<entry align="center"> 9.1 </entry>
|
||||
<entry><code> __has_include(<execution>) </code>,
|
||||
<code> __cpp_lib_execution >= 201603 </code>,
|
||||
<code> __cpp_lib_parallel_algorithm >= 201603 </code>
|
||||
(requires linking with <code>-ltbb</code>, see Note 3)
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -689,7 +690,7 @@ Feature-testing recommendations for C++</link>.
|
||||
</entry>
|
||||
<entry align="center"> 7.1 </entry>
|
||||
<entry><code> __cpp_lib_math_special_functions >= 201603 </code>
|
||||
(see Note 3)
|
||||
(see Note 4)
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -841,7 +842,13 @@ Note 2: This feature is supported in older releases but the
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note 3: The mathematical special functions are enabled in C++17 mode from
|
||||
Note 3: The Parallel Algorithms have an external dependency on Intel TBB 2018
|
||||
or later. If the <filename class="headerfile"><execution></filename>
|
||||
header is included then <code>-ltbb</code> must be used to link to TBB.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note 4: The mathematical special functions are enabled in C++17 mode from
|
||||
GCC 7.1 onwards. For GCC 6.x or for C++11/C++14 define
|
||||
<code>__STDCPP_WANT_MATH_SPEC_FUNCS__</code> to a non-zero value
|
||||
and test for <code>__STDCPP_MATH_SPEC_FUNCS__ >= 201003L</code>.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user