From: Jonathan Wakely <jwakely@redhat.com>
To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: [PATCH] Update references to C++17 in libstdc++ manual
Date: Thu, 19 Oct 2017 13:59:00 -0000 [thread overview]
Message-ID: <20171019135908.GA15963@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 105 bytes --]
* doc/xml/manual/status_cxx2017.xml: Update references to C++17
section numbers.
Committed to trunk.
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 4889 bytes --]
commit 834582b0c91337b031fa610e08c81ff1f2087f53
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Thu Oct 19 14:38:40 2017 +0100
Update references to C++17 in libstdc++ manual
* doc/xml/manual/status_cxx2017.xml: Update references to C++17
section numbers.
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
index fd66ac503a8..b5a65be12c9 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -935,49 +935,49 @@ Feature-testing recommendations for C++</link>.
</para>
<para>
- <emphasis>20.6.5 [optional.bad_optional_access]</emphasis>
+ <emphasis>23.6.5 [optional.bad_optional_access]</emphasis>
<code>what()</code> returns <literal>"bad optional access"</literal>.
</para>
<para>
- <emphasis>20.7.2 [variant.variant]</emphasis>
+ <emphasis>23.7.3 [variant.variant]</emphasis>
Whether <classname>variant</classname> supports over-aligned types
should be documented here.
</para>
<para>
- <emphasis>20.7.10 [variant.bad.access]</emphasis>
+ <emphasis>23.7.10 [variant.bad.access]</emphasis>
<code>what()</code> returns <literal>"Unexpected index"</literal>.
</para>
<para>
- <emphasis>20.12.5.2 [memory.resource.pool.options]</emphasis>
+ <emphasis>23.12.5.2 [memory.resource.pool.options]</emphasis>
The limits for maximum number of blocks and largest allocation size
supported by <classname>pool_options</classname> should be documented
here.
</para>
<para>
- <emphasis>20.12.6.1 [memory.resource.monotonic.buffer.ctor]</emphasis>
+ <emphasis>23.12.6.1 [memory.resource.monotonic.buffer.ctor]</emphasis>
The default <code>next_buffer_size</code> and growth factor should
be documented here.
</para>
<para>
- <emphasis>20.15.4.3 [meta.unary.prop]</emphasis>
+ <emphasis>23.15.4.3 [meta.unary.prop]</emphasis>
The predicate condition for
<code>has_unique_object_representations</code> is true for all scalar
types except floating point types.
</para>
<para>
- <emphasis>20.19.3 [execpol.type],
- 25.2.3 [algorithms.parallel.exec]</emphasis>
+ <emphasis>23.19.3 [execpol.type],
+ 28.4.3 [algorithms.parallel.exec]</emphasis>
There are no implementation-defined execution policies.
</para>
<para>
- <emphasis>22.4.2 [string.view.template]</emphasis>
+ <emphasis>24.4.2 [string.view.template]</emphasis>
<classname>basic_string_view<C, T>::iterator</classname> is
<code>C*</code> and
<classname>basic_string_view<C, T>::const_iterator</classname> is
@@ -986,7 +986,7 @@ Feature-testing recommendations for C++</link>.
<para>
- <emphasis>25.2.3 [algorithms.parallel.exec]</emphasis>
+ <emphasis>28.4.3 [algorithms.parallel.exec]</emphasis>
Threads of execution created by <classname>std::thread</classname>
provide concurrent forward progress guarantees, so threads of execution
implicitly created by the library will provide parallel forward
@@ -994,39 +994,39 @@ Feature-testing recommendations for C++</link>.
</para>
<para>
- <emphasis>26.4.1 [cfenv.syn]</emphasis>
+ <emphasis>29.4.1 [cfenv.syn]</emphasis>
The effects of the <filename><cfenv></filename> functions
depends on whether the <code>FENV_ACCESS</code> pragma is supported,
and on the C library that provides the header.
</para>
<para>
- <emphasis>26.6.9 [c.math.rand]</emphasis>
+ <emphasis>29.6.9 [c.math.rand]</emphasis>
Whether the <function>rand</function> function may introduce data
races depends on the target C library that provides the function.
</para>
<para>
- <emphasis>26.9.5 [sf.cmath]</emphasis>
+ <emphasis>29.9.5 [sf.cmath]</emphasis>
The effect of calling the mathematical special functions with large
inputs should be documented here.
</para>
<para>
- <emphasis>27.10.2.1 [fs.conform.9945]</emphasis>
+ <emphasis>30.10.2.1 [fs.conform.9945]</emphasis>
The behavior of the filesystem library implementation will depend on
the target operating system. Some features will not be not supported
on some targets.
</para>
<para>
- <emphasis>27.10.6 [fs.filesystem.syn]</emphasis>
+ <emphasis>30.10.5 [fs.filesystem.syn]</emphasis>
The clock used for file times is
<classname>std::chrono::system_clock</classname>.
</para>
<para>
- <emphasis>27.10.8 [path.generic]</emphasis>
+ <emphasis>30.10.7.1 [fs.path.generic]</emphasis>
dot-dot in the root-directory refers to the root-directory itself.
</para>
reply other threads:[~2017-10-19 13:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171019135908.GA15963@redhat.com \
--to=jwakely@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).