<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">

<title>C++ Freestanding and Conditionally Supported</title>

<style type="text/css">
table { border: 1px solid black; border-spacing: 0px }
caption { font-weight: bold }
th { text-align: left; vertical-align: top;
     padding: 0.5em; border: 1px solid black }
td { text-align: left; vertical-align: top;
     padding: 0.5em; border: 1px solid black }
dt { font-weight: bold; }
ins { background-color: #A0FFA0; }
del { background-color: #FFA0A0; }
</style>
</head>

<body>

<h1>C++ Freestanding and Conditionally Supported</h1>

<p>
ISO/IEC JTC1 SC22 WG21 N3256 = 11-0026 - 2011-02-27
</p>

<p>
Lawrence Crowl, crowl@google.com, Lawrence@Crowl.org
<br>
Alberto Ganesh Barbati, ganesh@barbati.net
</p>

<p>
<a href="#Introduction">Introduction</a><br>
<a href="#Freestanding">Freestanding Implementations</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#GB55">GB 55 Freestanding &lt;ratio&gt; and &lt;chrono&gt;</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#GB56">GB 56 Freestanding &lt;utility&gt; and &lt;tuple&gt;</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#GB57">GB 57 Freestanding &lt;atomic&gt;</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#C1Xfree">C1X Freestanding Compatibility</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#GB90">GB 90 Freestanding &lt;type_traits&gt;</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AtLeast">At Least as Much as C</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AtLeast.compliance">17.6.1.3 Freestanding implementations [compliance]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AvoidLarge">Avoid Large Implementations</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AvoidLarge.compliance">17.6.1.3 Freestanding implementations [compliance]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AvoidThread">Avoid Threading</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AvoidThread.compliance">17.6.1.3 Freestanding implementations [compliance]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AllowHelpers">Allow Small Helpers</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AllowHelpers.headers">17.6.1.2 Headers [headers]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AllowHelpers.compliance">17.6.1.3 Freestanding implementations [compliance]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<ins><a href="#AllowHelpers.helpers">20.? Helper components [helpers]</a></ins><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AllowHelpers.utility.swap"><del>20.3.2</del> <ins>20.?.1</ins> swap [utility.swap]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AllowHelpers.forward"><del>20.3.3</del> <ins>20.?.2</ins> forward/move helpers [forward]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AllowHelpers.declval"><del>20.3.4</del> <ins>20.?.3</ins> Function template <code>declval</code> [declval]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AllowHelpers.declval">20.3 Utility components [utility]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AllowTuple">Allow &lt;utility&gt; and &lt;tuple&gt;</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#AllowTuple.compliance">17.6.1.3 Freestanding implementations [compliance]</a><br>
<a href="#Conditional">Conditional Features</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#DE13">DE 13 Strict Pointer Macro</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#GB107">GB 107 Monotonic Clock Macro</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#DE23">DE 23 Threads Macro</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#C1Xcond">C1X Conditional Feature Compatibility</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#CondContents">Remove Conditional Contents</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#CondContents.compliance">17.6.1.3 Freestanding implementations [compliance]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#CondContents.thread.threads">30.3 Threads [thread.threads]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Predefined">Add Predefined Macros</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#Predefined.cpp.predefined">16.8 Predefined macro names [cpp.predefined]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#LibDefined">Add Library-Defined Macros</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#LibDefined.headers">17.6.1.2 Headers [headers]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#LibDefined.compliance">17.6.1.3 Freestanding implementations [compliance]</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#LibDefined.header.support"><ins>18.? Library header support [header.support]</ins></a><br>
</p>


<h2><a name="Introduction">Introduction</a></h2>

<p>
Several issues have centered on
the requirements on freestanding implementations
and the indication of conditionally supported behavior.
We list those issues, discuss the general problems,
propose solutions, and provide wording.
</p>


<h2><a name="Freestanding">Freestanding Implementations</a></h2>

<p>
C++ has no defined policy
for choosing what belongs in freestanding headers and what does not.
As a consequence, this aspects of the standard
is incomplete and inconsistent.
</p>


<h3><a name="GB55">GB 55 Freestanding &lt;ratio&gt; and &lt;chrono&gt;</a></h3>

<dl>

<dt>Section</dt>
<dd>
17.6.1.3 table 15
</dd>

<dt>Comment</dt>
<dd>
The thread header uses duration types,
found in the &lt;chrono&gt; header,
and which rely on the ratio types declared in the &lt;ratio&gt; header.
</dd>

<dt>Proposal</dt>
<dd>
Add the &lt;chrono&gt; and &lt;ratio&gt; headers
to the freestanding requirements.
It might be necessary to address scaled-down expectations of clock support
in a freestanding environment, much like &lt;thread&gt;.
</dd>

<dt>Issue</dt>
<dd>
<a href="http://lwg.github.com/issues/lwg-toc.html#1358">LWG 1359</a>
</dd>

<dt>Status</dt>
<dd>
Open
</dd>

<dt>Resolution</dt>
<dd>
See the proposed resolution in
<a href="http://lwg.github.com/issues/lwg-toc.html#1358">LWG 1359</a>.
</dd>

</dl>


<h3><a name="GB56">GB 56 Freestanding &lt;utility&gt; and &lt;tuple&gt;</a></h3>

<dl>

<dt>Section</dt>
<dd>
17.6.1.3 table 15
</dd>

<dt>Comment</dt>
<dd>
The &lt;utility&gt; header
provides support for several important C++ idioms
with move, forward and swap.
Likewise, declval will be frequently used like a type trait.
In order to complete cycles introduced by std::pair,
the &lt;tuple&gt; header should also be made available.
This is a similarly primitive set of functionality,
with no dependency of a hosted environment,
but does go beyond the minimal set of functionality
otherwise suggested by the freestanding libraries.
Alternatively,
split the move/forward/swap/declval functions out of &lt;utility&gt;
and into a new primitive header,
requiring only that of freestanding implementation.
</dd>

<dt>Proposal</dt>
<dd>
Add &lt;utility&gt; and &lt;tuple&gt; to table 15,
headers required for a free-standing implementation.
</dd>

<dt>Issue</dt>
<dd>
<a href="http://lwg.github.com/issues/lwg-toc.html#1359">LWG 1359</a>
</dd>

<dt>Status</dt>
<dd>
NAD
</dd>

<dt>Rationale</dt>
<dd>
No consensus for change.
</dd>

</dl>


<h3><a name="GB57">GB 57 Freestanding &lt;atomic&gt;</a></h3>

<dl>

<dt>Section</dt>
<dd>
17.6.1.3 table 15
</dd>

<dt>Comment</dt>
<dd>
The atomic operations facility
is closely tied to clause 1 and the memory model.
It is not easily supplied as an after-market extension,
and should be trivial to implement of a single-threaded serial machine.
The consequence of not having this facility
will be poor interoperability with future C++ libraries
that memory model concerns seriously,
and attempt to treat them in a portable way.
</dd>

<dt>Proposal</dt>
<dd>
Add &lt;atomic&gt; to table 15,
headers required for a free-standing implementation.
</dd>

<dt>Issue</dt>
<dd>
<a href="http://lwg.github.com/issues/lwg-toc.html#1360">LWG 1360</a>
</dd>

<dt>Status</dt>
<dd>
Resolved in
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3225.pdf">N3225</a>.
</dd>

<dt>Resolution</dt>
<dd>
Add &lt;atomic&gt; to table 15,
headers required for a free-standing implementation.
</dd>

</dl>


<h3><a name="C1Xfree">C1X Freestanding Compatibility</a></h3>

<dl>

<dt>Section</dt>
<dd>
17.6.1.3
</dd>

<dt>Comment</dt>
<dd>
<p>
The C++ working draft
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3225.pdf">N3225</a>
requires freestanding implementations to provide:
&lt;atomic&gt;
&lt;exception&gt;
&lt;initializer_list&gt;
&lt;limits&gt;
&lt;new&gt;
&lt;cstdarg&gt;
&lt;cstddef&gt;
&lt;cstdlib&gt;
&lt;thread&gt;
&lt;type_traits&gt;
&lt;typeinfo&gt;
</p>

<p>
The C working draft
<a href="http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1539.pdf">N1539</a>
section 4 paragraph 6
requires freestanding implementations to provide:
&lt;float.h&gt;
&lt;iso646.h&gt;
&lt;limits.h&gt;
&lt;stdalign.h&gt;
&lt;stdarg.h&gt;
&lt;stdbool.h&gt;
&lt;stddef.h&gt;
&lt;stdint.h&gt;
</p>

<p>
These two requirements have notable inconsistencies.
</p>
<ul>
<li>
The <code>*.h</code> forms of the headers are not required by the C++,
though they are by C.
</li>

<li>
C++ is missing some required C headers and their C++ equivalents:
&lt;float.h&gt; &lt;cfloat&gt;
&lt;iso646.h&gt; &lt;ciso646&gt;
&lt;limits.h&gt; &lt;climits&gt;
&lt;stdalign.h&gt; &lt;cstdalign&gt;
&lt;stdarg.h&gt;
&lt;stdbool.h&gt; &lt;cstdbool&gt;
&lt;stddef.h&gt;
&lt;stdint.h&gt; &lt;cstdint&gt;
</li>

<li>
C++ requires headers (or equivalents) explicitly not required by C:
&lt;atomic&gt; &lt;stdatomic.h&gt; (presumed) &lt;cstdatomic&gt; (presumed)
&lt;stdlib.h&gt; &lt;cstdlib&gt;
&lt;thread&gt; &lt;threads.h&gt;
</li>
</ul>

<p>
Taken as a whole, the C specification for freestanding implementations
does not require run-time library support:
memory allocation, string routines, and input/output.
This is in marked contrast to C++,
which seems to require more than necessary.
</p>

</dd>
</dl>


<h3><a name="GB90">GB 90 Freestanding &lt;type_traits&gt;</a></h3>

<dl>

<dt>Section</dt>
<dd>
20.7
</dd>

<dt>Comment</dt>
<dd>
type_traits is a core support facility offered by the compiler,
and exposed with a library interface
that is required in a free-standing implementation.
It has far more in common with numeric_limits
than the utility components in clause 20,
and should move to clause 18.
</dd>

<dt>Proposal</dt>
<dd>
Move clause 20.7 into clause 18.
</dd>

<dt>Issue</dt>
<dd>
None.
</dd>

<dt>Status</dt>
<dd>
Rejected.
</dd>

<dt>Rationale</dt>
<dd>
Type traits support queries about all types, not just built-in types.
They do not belong in Clause 18.
</dd>

</dl>


<h3><a name="AtLeast">At Least as Much as C</a></h3>

<p>
The set of freestanding headers required by C++
should include at least those required by C.
Implementors will anyway because few would support only C++,
so failing to support those headers simply invites
an inconsistency between the standard and practice.
</p>


<h4><a name="AtLeast.compliance">17.6.1.3 Freestanding implementations [compliance]</a></h4>

<p>
Edit table 16 as follows.
</p>

<blockquote>
<table>
<caption>Table 16 &mdash; C++ headers for freestanding implementations</caption>
<thead>
<tr><th></th><th>Subclause</th><th>Header(s)</th></tr>
</thead>
<tbody>
<tr><td><ins>17.6.1.2, C.2.2.3</ins></td><td><ins>Named operators</ins></td>
<td><ins><code>&lt;ciso646&gt; &lt;iso646.h&gt;</code></ins></td></tr>
<tr><td>18.2</td><td>Types</td>
<td><code>&lt;cstddef&gt; <ins>&lt;stddef.h&gt;</ins></code></td></tr>
<tr><td>18.3</td><td>Implementation properties</td>
<td><code><ins>&lt;cfloat&gt; &lt;float.h&gt;</ins>
&lt;limits&gt; <ins>&lt;climits&gt; &lt;limits.h&gt;</ins></code></td></tr>
<tr><td><ins>18.4</ins></td><td><ins>Integer types</ins></td>
<td><ins><code>&lt;cstdint&gt; &lt;stdint.h&gt;</code></ins></td></tr>
<tr><td>...</td><td>...</td><td>...</td></tr>
<tr><td>18.10</td><td>Other runtime support</td>
<td><code><ins>&lt;cstdalign&gt; &lt;stdalign.h&gt;</ins>
&lt;cstdarg&gt; <ins>&lt;stdarg.h&gt;</ins>
<ins>&lt;cstdbool&gt; &lt;stdbool.h&gt;</ins>
</code></td></tr>
<tr><td>...</td><td>...</td><td>...</td></tr>
</tbody>
</table>
</blockquote>


<h3><a name="AvoidLarge">Avoid Large Implementations</a></h3>

<p>
Since freestanding implementations are generally for embedded systems,
the requirements should not require significant run-time implementation.
The C standards community is generally closer to embedded systems,
and the list of C freestanding headers reflects lean implementations.
C++ policy should do the same.
</p>

<p>
In particular,
C does not require &lt;stdlib.h&gt; in freestanding implementations
because of the run-time overhead embodied in that header.
Even though C++ only requires a subset of &lt;stdlib.h&gt;,
requiring it would still be a burden on some implementations.
Likewise,
features requiring dynamic memory allocation
or unneeded code size are also often avoided in embedded systems.
The headers &lt;exception&gt;, &lt;new&gt;, and &lt;typeinfo&gt;
are in this class.
They would also be a burden on some implementations.
(We recognize that their absence would prevent use of some language features,
but such systems already prohibit their use.)
</p>

<h4><a name="AvoidLarge.compliance">17.6.1.3 Freestanding implementations [compliance]</a></h4>

<p>
Edit table 16 as follows.
</p>

<blockquote>
<table>
<caption>Table 16 &mdash; C++ headers for freestanding implementations</caption>
<thead>
<tr><th></th><th>Subclause</th><th>Header(s)</th></tr>
</thead>
<tbody>
<tr><td>...</td><td>...</td><td>...</td></tr>
<tr><td><del>18.5</del></td><td><del>Start and termination</del></td>
<td><del><code>&lt;cstdlib&gt;</code></del></td></tr>
<tr><td><del>18.6</del></td><td><del>Dynamic memory management</del></td>
<td><del><code>&lt;new&gt;</code></del></td></tr>
<tr><td><del>18.7</del></td><td><del>Type identification</del></td>
<td><del><code>&lt;typeinfo&gt;</code></del></td></tr>
<tr><td><del>18.8</del></td><td><del>Exception handling</del></td>
<td><del><code>&lt;exception&gt;</code></del></td></tr>
<tr><td>...</td><td>...</td><td>...</td></tr>
</tbody>
</table>
</blockquote>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote>
<p>
<del>The supplied version of the header <code>&lt;cstdlib&gt;</code>
shall declare at least the functions
<code>abort</code>, <code>atexit</code>, <code>at_quick_exit</code>,
<code>exit</code>, and <code>quick_exit</code> (18.5).</del>
The supplied version of the header <code>&lt;thread&gt;</code>
shall meet the same requirements as for a hosted implementation
or including it shall have no effect.
The other headers listed in this table
shall meet the same requirements as for a hosted implementation.
</p>
</blockquote>

<h3><a name="AvoidThread">Avoid Threading</a></h3>

<p>
Atomics are fairly tightly integrated into the language,
and are required on any concurrent system.
On systems without concurrency, atomics have trivial implementation.
So under the above criteria,
as suggested by <a href="#GB57">GB 57</a>,
should be included in the freestanding headers.
</p>

<p>
In contrast, &lt;mutex&gt;
is more likely to be implemented in freestanding implementations
than is &lt;thread&gt;
and yet their freestanding requirements are opposite.
Furthermore, there are many single-threaded embedded systems.
So, &lt;thread&gt; should not be required of freestanding implementations.
Consequently,
&lt;ratio&gt; and &lt;chrono&gt; would not need to be freestanding
and <a href="#GB55">GB 55</a> would become moot.
</p>


<h4><a name="AvoidThread.compliance">17.6.1.3 Freestanding implementations [compliance]</a></h4>

<p>
Edit table 16 as follows.
</p>

<blockquote>
<table>
<caption>Table 16 &mdash; C++ headers for freestanding implementations</caption>
<thead>
<tr><th></th><th>Subclause</th><th>Header(s)</th></tr>
</thead>
<tbody>
<tr><td>...</td><td>...</td><td>...</td></tr>
<tr><td>29</td><td>Atomics</td>
<td><code>&lt;atomic&gt;</code></td></tr>
<tr><td><del>30.3</del></td><td><del>Threads</del></td>
<td><del><code>&lt;thread&gt;</code></del></td></tr>
</tbody>
</table>
</blockquote>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote>
<p>
The supplied version of the header <code>&lt;cstdlib&gt;</code>
shall declare at least the functions
<code>abort</code>, <code>atexit</code>, <code>at_quick_exit</code>,
<code>exit</code>, and <code>quick_exit</code> (18.5).
<del>The supplied version of the header <code>&lt;thread&gt;</code>
shall meet the same requirements as for a hosted implementation
or including it shall have no effect.</del>
The other headers listed in this table
shall meet the same requirements as for a hosted implementation.
</p>
</blockquote>


<h3><a name="AllowHelpers">Allow Small Helpers</a></h3>

<p>
C++ is necessarily a larger language than C,
and the line between the language and the library is fuzzier.
C++ should be willing and able
to incorporate headers into freestanding implementations
when the need is apparent and the run-time implementation is small.
</p>

<p>
As an example,
rvalue references are very difficult to use
without (at least replicating)
some of the facilities defined in &lt;utility&gt;.
Their implementation is tiny.
So, <a href="#GB56">GB 56</a> should be reconsidered.
At a minimum,
the move, forward, swap, and declval functions
should be split into a separate header.
</p>


<h4><a name="AllowHelpers.headers">17.6.1.2 Headers [headers]</a></h4>

<blockquote>
<table>
<caption>Table 14 &mdash; C++ library headers</caption>
<tr><td>....</td></tr>
<tr><td><code>&lt;future&gt;</code></td></tr>
<tr><td><ins><code>&lt;helpers&gt;</code></ins></td></tr>
<tr><td><code>&lt;initializer_list&gt;</code></td></tr>
<tr><td>....</td></tr>
</table>
</blockquote>  


<h4><a name="AllowHelpers.compliance">17.6.1.3 Freestanding implementations [compliance]</a></h4>

<p>
Edit table 16 as follows.
</p>

<blockquote>
<table>
<caption>Table 16 &mdash; C++ headers for freestanding implementations</caption>
<thead>
<tr><th></th><th>Subclause</th><th>Header(s)</th></tr>
</thead>
<tbody>
<tr><td>...</td><td>...</td><td>...</td></tr>
<tr><td><ins>20.?</ins></td><td><ins>Helper components</ins></td>
<td><ins><code>&lt;helpers&gt;</code></ins></td></tr>
<tr><td>20.7</td><td>Type traits</td>
<td><code>&lt;type_traits&gt;</code></td></tr>
<tr><td>...</td><td>...</td><td>...</td></tr>
</tbody>
</table>
</blockquote>


<h4><ins><a name="AllowHelpers.helpers">20.? Helper components [helpers]</a></ins></h4>

<p>
Create a new section "Helper components"
before 20.3 Utility components [utility].
</p>

<p>
Add a paragraph 1.
</p>

<blockquote>
<p>
<ins>This subclause contains some basic function and class templates
that are used throughout the rest of the library.</ins>
</p>
</blockquote>

<p>
Add a synopsis.
</p>

<blockquote>
<dl>
<dt><ins>Header <code>&lt;helpers&gt;</code> synopsis</ins></dt>
<dd>
<pre><code><ins>
namespace std {

// 20.?.1, swap:
template&lt;class T&gt; void swap(T&amp; a, T&amp; b) noexcept(<var>see below</var>);
template &lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]) noexcept(noexcept(swap(*a, *b)));

// 20.?.2, forward/move:
template &lt;class T&gt; T&amp;&amp; forward(typename remove_reference&lt;T&gt;::type&amp; t) noexcept;
template &lt;class T&gt; T&amp;&amp; forward(typename remove_reference&lt;T&gt;::type&amp;&amp; t) noexcept;
template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp;) noexcept;
template &lt;class T&gt; typename conditional&lt;
  !is_nothrow_move_constructible&lt;T&gt;::value &amp;&amp; is_copy_constructible&lt;T&gt;::value,
  const T&amp;, T&amp;&amp;&gt;::type move_if_noexcept(T&amp; x) noexcept;

// 20.?.3, declval:
template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type declval() noexcept;  // as unevaluated operand

}
</ins></code></pre>
</dd>
</dl>
</blockquote>


<h4><a name="AllowHelpers.utility.swap"><del>20.3.2</del> <ins>20.?.1</ins> swap [utility.swap]</a></h4>

<p>
Move the entire subsubclause 20.3.2 into the new subclause above.
</p>


<h4><a name="AllowHelpers.forward"><del>20.3.3</del> <ins>20.?.2</ins> forward/move helpers [forward]</a></h4>

<p>
Move the entire subsubclause 20.3.3 into the new subclause above.
</p>


<h4><a name="AllowHelpers.declval"><del>20.3.4</del> <ins>20.?.3</ins> Function template <code>declval</code> [declval]</a></h4>

<p>
Move the entire subsubclause 20.3.4 into the new subclause above.
</p>


<h4><a name="AllowHelpers.utility">20.3 Utility components [utility]</a></h4>

<p>
Edit the synopsis as follows.
</p>

<blockquote>
<dl>
<dt>Header <code>&lt;utility&gt;</code> synopsis</dt>
<dd>
<pre><code>
#include &lt;initializer_list&gt;
<ins>#include &lt;helpers&gt;</ins>

namespace std {

....

<del>// 20.3.2, swap:
template&lt;class T&gt; void swap(T&amp; a, T&amp; b) noexcept(<var>see below</var>);
template &lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]) noexcept(noexcept(swap(*a, *b)));</del>

<del>// 20.3.3, forward/move:
template &lt;class T&gt; T&amp;&amp; forward(typename remove_reference&lt;T&gt;::type&amp; t) noexcept;
template &lt;class T&gt; T&amp;&amp; forward(typename remove_reference&lt;T&gt;::type&amp;&amp; t) noexcept;
template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp;) noexcept;
template &lt;class T&gt; typename conditional&lt;
  !is_nothrow_move_constructible&lt;T&gt;::value &amp;&amp; is_copy_constructible&lt;T&gt;::value,
  const T&amp;, T&amp;&amp;&gt;::type move_if_noexcept(T&amp; x) noexcept;</del>

<del>// 20.3.4, declval:
template &lt;class T&gt;
  typename add_rvalue_reference&lt;T&gt;::type declval() noexcept;  // as unevaluated operand</del>

....

</code></pre>
</dd>
</dl>
</blockquote>


<h3><a name="AllowTuple">Allow &lt;utility&gt; and &lt;tuple&gt;</a></h3>

<p>
As an alternative to the change above,
we could do all that <a href="#GB56">GB 56</a> requests.
</p>


<h4><a name="AllowTuple.compliance">17.6.1.3 Freestanding implementations [compliance]</a></h4>

<p>
Edit table 16 as follows.
</p>

<blockquote>
<table>
<caption>Table 16 &mdash; C++ headers for freestanding implementations</caption>
<thead>
<tr><th></th><th>Subclause</th><th>Header(s)</th></tr>
</thead>
<tbody>
<tr><td>...</td><td>...</td><td>...</td></tr>
<tr><td><ins>20.3</ins></td><td><ins>Utility components</ins></td>
<td><ins><code>&lt;utility&gt;</code></ins></td></tr>
<tr><td><ins>20.4</ins></td><td><ins>Tuples</ins></td>
<td><ins><code>&lt;tuple&gt;</code></ins></td></tr>
<tr><td>20.7</td><td>Type traits</td>
<td><code>&lt;type_traits&gt;</code></td></tr>
<tr><td>...</td><td>...</td><td>...</td></tr>
</tbody>
</table>
</blockquote>


<h2><a name="Conditional">Conditional Features</a></h2>

<p>
C++ has no defined mechanism
for indicating conditional features.
As a consequence, this aspects of the standard
is incomplete and inconsistent.
</p>


<h3><a name="DE13">DE 13 Strict Pointer Macro</a></h3>

<dl>

<dt>Section</dt>
<dd>
16.8
</dd>

<dt>Comment</dt>
<dd>
Committee Draft comment DE 18 has only been partially addressed,
and the record of response ignores the missing item,
namely the absence of a macro __STDCPP_STRICT_POINTER_SAFETY__
that indicates that a given implementation has strict pointer safety
(see 3.7.4.3).
</dd>

<dt>Proposal</dt>
<dd>
Add the macro to the list of predefined macros in 16.8.
</dd>

<dt>Issue</dt>
<dd>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html#1169">CWG 1169</a>
</dd>

<dt>Status</dt>
<dd>
Resolved November 2010
</dd>

<dt>Resolution</dt>
<dd>
Add the following to the end of 16.8 [cpp.predefined] paragraph 2:
<blockquote>
<dl>
<dt><code>__STDCPP_STRICT_POINTER_SAFETY__</code></dt>
<dd>
Defined, and has the value integer constant 1,
if and only if the implementation has strict pointer safety
(3.7.4.3 [basic.stc.dynamic.safety]).
</dd>
</dl>
</blockquote>
</dd>

</dl>


<h3><a name="GB107">GB 107 Monotonic Clock Macro</a></h3>

<dl>

<dt>Section</dt>
<dd>
20.10.5.2 paragraph 2
</dd>

<dt>Comment</dt>
<dd>
1.4p9 states that which conditionally supported constructs
are available should be provided in the documentation for the implementation.
This doesn't help programmers trying to write portable code,
as they must then rely on implementation-specific means
to determine the availability of such constructs.
In particular,
the presence or absence of std::chrono::monotonic_clock
may require different code paths to be selected.
This is the only conditionally-supported library facility,
and differs from the conditionally-supported language facilities
in that it has standard-defined semantics
rather than implementation defined semantics.
</dd>

<dt>Proposal</dt>
<dd>
Provide feature test macro
for determining the presence of std::chrono::monotonic_clock.
Add _STDCPP_HAS_MONOTONIC_CLOCK to the &lt;chrono&gt; header,
which is defined if monotonic_clock is present,
and not defined if it is not present.
</dd>

<dt>Issue</dt>
<dd>
<a href="http://lwg.github.com/issues/lwg-toc.html#1410">LWG 1410</a>
</dd>

<dt>Status</dt>
<dd>
Resolved
</dd>

<dt>Resolution</dt>
<dd>
Moot by the conversion of
conditionally-supported monotonic clocks to required steady clocks
in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.html">N3191</a>.
</dd>

</dl>


<h3><a name="DE23">DE 23 Threads Macro</a></h3>

<dl>

<dt>Section</dt>
<dd>
30.3
</dd>

<dt>Comment</dt>
<dd>
Predefined macros usually start and end with two underscores,
see 16.8 and FDIS 29124 = WG21 N3060 clause 7.
__STDCPP_THREADS should blend in.
</dd>

<dt>Proposal</dt>
<dd>
Change the macro name to __STDCPP_THREADS__.
</dd>

<dt>Issue</dt>
<dd>
<a href="http://lwg.github.com/issues/lwg-toc.html#1483">LWG 1483</a>
</dd>

<dt>Status</dt>
<dd>
NAD Editorial.
</dd>

<dt>Resolution</dt>
<dd>
Change the macro name to __STDCPP_THREADS__.
</dd>

</dl>


<h3><a name="C1Xcond">C1X Conditional Feature Compatibility</a></h3>

<dl>

<dt>Section</dt>
<dd>
Various.
</dd>

<dt>Comment</dt>
<dd>

<p>
The C working draft
<a href="http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1539.pdf">N1539</a>
section 6.10.8.3 paragraph 1
requires conditionally macros
indicating (lack of) support for conditional features.
</p>

<dl>
<dt>__STDC_ANALYZABLE__</dt>
<dd>
The integer constant 1,
intended to indicate conformance
to the specifications in annex L (Analyzability).
</dd>
<dt>__STDC_IEC_559__</dt>
<dd>
The integer constant 1,
intended to indicate conformance
to the specifications in annex F (IEC 60559 floating-point arithmetic).
</dd>
<dt>__STDC_IEC_559_COMPLEX__</dt>
<dd>
The integer constant 1,
intended to indicate adherence
to the specifications in annex G (IEC 60559 compatible complex arithmetic).
</dd>
<dt>__STDC_LIB_EXT1__</dt>
<dd>
The integer constant 201ymmL,
intended to indicate support for
the extensions defined in annex K (Bounds-checking interfaces).
</dd>
<dt>__STDC_NO_COMPLEX__</dt>
<dd>
The integer constant 1,
intended to indicate that
the implementation does not support complex types
or the &lt;complex.h&gt; header.
</dd>
<dt>__STDC_NO_THREADS__</dt>
<dd>
The integer constant 1, intended to indicate that
the implementation does not support atomic types
(including the _Atomic type qualifier and the &lt;stdatomic.h&gt; header)
or the &lt;threads.h&gt; header.
</dd>
<dt>__STDC_NO_VLA__</dt>
<dd>
The integer constant 1,
intended to indicate that
the implementation does not support variable length arrays
or variably modified types.
</dd>
</dl>

<p>
(Note that there are NB comments on C1x against the current
formulation of __STDC_NO_THREADS__.)
</p>

<p>
In constrast,
The C++ working draft
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3225.pdf">N3225</a>
generally ignores conditional behavior,
except that
the &lt;thread&gt; header either defines
_STDCPP_THREADS__ and the full set of symbols,
or has no effect.
This mechanism is different from that of C,
and more difficult to use.
</p>

</dd>
</dl>


<h3><a name="CondContents">Remove Conditional Contents</a></h3>

<p>
Most programmers will not write code that adapts
to the presence or absence of conditional features.
As a consequence,
the use of a missing feature should be transparently obvious.
Therefore,
if a feature is missing,
the C++ implementation should simply not provide the corresponding header.
The error message will be brutally obvious &mdash; header not found.
</p>

<p>
In C++ 2003, there are no macros indicating C++ conditional features.
We could as well do the same thing in C++0x,
which would serve the vast majority of programmers.
</p>

<p>
Therefore, we should remove the __STDCPP_THREADS__ macro
from &lt;thread&gt;.
</p>


<h4><a name="CondContents.compliance">17.6.1.3 Freestanding implementations [compliance]</a></h4>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote>
<p>
The supplied version of the header <code>&lt;cstdlib&gt;</code>
shall declare at least the functions
<code>abort</code>, <code>atexit</code>, <code>at_quick_exit</code>,
<code>exit</code>, and <code>quick_exit</code> (18.5).
<del>The supplied version of the header <code>&lt;thread&gt;</code>
shall meet the same requirements as for a hosted implementation
or including it shall have no effect.</del>
The other headers listed in this table
shall meet the same requirements as for a hosted implementation.
</p>
</blockquote>


<h4><a name="CondContents.thread.threads">30.3 Threads [thread.threads]</a></h4>

<p>
Edit the synopsis as follows.
</p>

<blockquote>
<pre><code>
namespace std {
  <del>#define __STDCPP_THREADS__ __cplusplus</del>
</code></pre>
<p>
....
</p>
</blockquote>


<h3><a name="Predefined">Add Predefined Macros</a></h3>

<p>
Some programmers can and would will write code
that adapts to the presence or absence of conditional features,
if a language mechanism were available.
</p>

<p>
C uses predefined macros to indicate conditional features.
C++ could do the same.
</p>

<p>
C uses a mix of positive and negative sense macros.
C++ defines mostly positive macros in 16.8 [cpp.predefined].
As postive sense macros are easier to reason with,
we should use them.
</p>

<p>
So, we should add a predefined __STDCPP_THREADS__ macro.
</p>

<p>
As it is somewhat likely that other thread-related headers
will be implemented or not in concert with &lt;thread&gt;,
we should make those headers conditional under the same macro.
</p>

<h4><a name="Predefined.cpp.predefined">16.8 Predefined macro names [cpp.predefined]</a></h4>

<p>
Add the following to the end of paragraph 2.
</p>

<blockquote>
<dl>
<dt><code>__STDCPP_THREAD__</code></dt>
<dd>
Defined, and has the value integer constant 1,
if and only if the implementation provides the headers
&lt;condition_variable&gt; (30.5 [thread.condition]),
&lt;future&gt; (30.6 [futures]),
&lt;mutex&gt; (30.4 [thread.mutex]),
and &lt;thread&gt; (30.3 [thread.threads]).
</dd>
</dl>
</blockquote>


<h3><a name="LibDefined">Add Library-Defined Macros</a></h3>

<p>
As an alternative to the approach above,
we can provide a library header that provides
the macros indicating whether or not a header is present,
as suggested in the proposed resolution to
<a href="http://lwg.github.com/issues/lwg-active.html#1358">LWG 1358</a>.
This approach has the virtue
of moving indications of library features to the library implementation.
Its cost is that library implementations
must provide another header
and programmers testing conditional features
would need to include that header.
</p>


<h4><a name="LibDefined.headers">17.6.1.2 Headers [headers]</a></h4>

<blockquote>
<table>
<caption>Table 14 &mdash; C++ library headers</caption>
<tr><td>....</td></tr>
<tr><td><code>&lt;iterator&gt;</code></td></tr>
<tr><td><ins><code>&lt;library_support&gt;</code></ins></td></tr>
<tr><td><code>&lt;limits&gt;</code></td></tr>
<tr><td>....</td></tr>
</table>
</blockquote>  


<h4><a name="LibDefined.compliance">17.6.1.3 Freestanding implementations [compliance]</a></h4>

<p>
Edit table 16 as follows.
</p>

<blockquote>
<table>
<caption>Table 16 &mdash; C++ headers for freestanding implementations</caption>
<thead>
<tr><th></th><th>Subclause</th><th>Header(s)</th></tr>
</thead>
<tbody>
<tr><td>...</td><td>...</td><td>...</td></tr>
<tr><td><ins>20.?</ins></td><td><ins>Library header support</ins></td>
<td><ins><code>&lt;library_support&gt;</code></ins></td></tr>
<tr><td>20.7</td><td>Type traits</td>
<td><code>&lt;type_traits&gt;</code></td></tr>
<tr><td>...</td><td>...</td><td>...</td></tr>
</tbody>
</table>
</blockquote>

<p>
Edit paragraph 3 as follows.
</p>

<blockquote><p>
The supplied version of the header <code>&lt;cstdlib&gt;</code>
shall declare at least the functions
<code>abort</code>, <code>atexit</code>, <code>at_quick_exit</code>,
<code>exit</code>, and <code>quick_exit</code> (18.5).
<del>The supplied version of the header <code>&lt;thread&gt;</code>
shall meet the same requirements as for a hosted implementation
or including it shall have no effect</del>.
The other headers listed in this table shall meet the same requirements as for a hosted 
implementation. <ins>A program can detect the presence of standard headers not listed in Table
16 using the facilities provided by the <code>&lt;library_support&gt;</code> header.</ins>

</p></blockquote>

<h4><a name="LibDefined.header.support"><ins>18.? Library header support [header.support]</ins></a></h4>
 
<p>
Add a new section in Clause 18.
</p>

<p>
Add a new paragraph as follows.
</p>

<blockquote><p>
<ins>The header <code>&lt;library_support&gt;</code>
defines an implementation-defined set of macros
to enable a program detect the presence of standard headers
in freestanding implementations.
[<i>Note:</i>
Hosted implementations shall provide all standard headers,
thus shall provide all macros.
&mdash;<i>end note</i>]</ins>
</p></blockquote>

<p>
Add a new paragraph as follows.
</p>

<blockquote><p>
<ins>For each standard header listed in
Tables 14 (C++ library headers) and 15 (C++ headers for C library facilities)
that is provided by the implementation,
<code>&lt;library_support&gt;</code> shall define a macro with name 
<code>__STDCPP_HAS_<var>XXX</var>_HEADER__</code>
where <code><var>XXX</var></code>
is replaced by the uppercase version of the name of the header.
Each such macro shall expand to the value <code>__cplusplus</code>.
</ins>
</p></blockquote>

<p>
Add a new paragraph as follows.
</p>

<blockquote>
<p>
<ins>
[<i>Example:</i>
</ins>
</p>
<blockquote><pre><code>
<ins>#include &lt;library_support&gt;

#ifdef __STDCPP_HAS_THREAD_HEADER__
  #include &lt;thread&gt;
  // code that exploit the presence of threads
#else
  // fallback code that doesn't rely on threads
#endif</ins>
</code></pre></blockquote>
<p>
<ins>
&mdash;<i>end example</i>]
</ins>
</p>
</blockquote>

<p>
Add a new paragraph as follows.
</p>

<blockquote><p>
<ins>No other standard header
shall define macros with a name beginning with <code>__STDCPP_HAS_</code>
and ending with <code>_HEADER__</code>.</ins>
</p></blockquote>

</body>
</html>
