﻿<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Feature-testing recommendations for C++</title>
	<style type="text/css">
		tr
		{
			page-break-inside: avoid;
		}
		.editornote
		{
			font-family: Cursive;
			background-color: Yellow;
		}
		.boxed
		{
			border: solid;
		}
		h2:before
		{
			content: "[" counter(h2) "]\A0\A0\A0";
		}
		h3:before
		{
			content: "[" counter(h2) "." counter(h3) "]\A0\A0\A0";
		}
		h4:before
		{
			/* content: "[" counter(h2) "." counter(h3) "." counter(h4) "]\A0\A0\A0"; */
		}
		h1
		{
			counter-reset: h2 -2;
		}
		h2
		{
			page-break-after: avoid;
			counter-increment: h2;
			counter-reset: h3 h4 p;
		}
		h3
		{
			page-break-after: avoid;
			counter-increment: h3;
			counter-reset: h4 p;
		}
		h4
		{
			page-break-after: avoid;
			counter-increment: h4;
			counter-reset: p;
		}
		body > p:before
		{
			content: "[" counter(p) "]\A0\A0\A0";
		}
		body > p
		{
			counter-increment: p;
		}
	</style>
</head>
<body>
	<table border="1" summary="This table provides identifying information for this document.">
		<tr>
			<th>Doc. No.:</th>
			<td>N3694</td>
		</tr>
		<tr>
			<th>Date:</th>
			<td>2013-06-27</td>
		</tr>
		<tr>
			<th>Reply to:</th>
			<td>Clark Nelson</td>
		</tr>
		<tr>
			<th>Title:</th>
			<td>Feature-testing recommendations for C++</td>
		</tr>
	</table>
	<h1>Feature-testing recommendations for C++</h1>
	<h2>Preface</h2>
	<p>The more time that passes without any sort of feature-testing recommendation, the
		more confusion will affect programmers and implementers interested in features of
		C++14, of the sort that has plagued C++11 for years. So whatever action should be
		taken in this arena should not be delayed any more than can be avoided.</p>
	<p>SG10 intends to produce its recommendations solely as a WG21 document, without any
		balloting at higher levels. This is partly to save time, but also to avoid making
		significant conformance changes. It is hoped that compiler and library implementers
		will follow these recommendations voluntarily, even without the threat of claims
		of non-conformance. To improve the chances of that happening, it is considered important
		to have a record of the endorsement of WG21 &ndash; or at least of the C++ technical
		experts who attend WG21 meetings. </p>
	<p>So SG10 would like to bring this document forward for some sort of approval vote
		at the Chicago meeting. Formally speaking, no action by the committee is requested,
		so this vote should probably be just a straw poll.</p>
	<p>Note that this document recommends that the <code>__has_include</code> feature be
		provided in the C++14 time frame, even though it is not included in the CD for C++14.
		A conceivable alternative would be to add <code>__has_include</code> to C++14 before
		its final publication.</p>
	<p><em>This revision of this document contains STUBS for sections expected to be filled
		in later.</em></p>
	<h2>Contents</h2>
	<ol>
		<li><a href="#expl">Explanation and rationale for the approach</a> <ol>
			<li><a href="#expl.prob">Problem statement</a></li>
			<li><a href="#expl.status">Status quo</a></li>
			<li><a href="#expl.soln">Characteristics of the proposed solution</a></li>
		</ol></li>
		<li><a href="#recs">Recommendations</a> <ol>
			<li><a href="#recs.intro">Introduction</a></li>
			<li><a href="#recs.hasinc">Testing for the presence of a header: <code>__has_include</code></a></li>
			<li><a href="#recs.cpp14">C++14 features</a></li>
			<li><a href="#recs.cpp11">C++11 features</a> <em>(STUB)</em></li>
			<li><a href="#recs.condsupp">Conditionally-supported constructs</a> <em>(STUB)</em></li>
			<li><a href="#recs.cpp98">C++98 features</a> <em>(STUB)</em></li>
		</ol></li>
		<li><a href="#detail">Detailed explanation and rationale</a> <ol>
			<li><a href="#detail.cpp14">C++14 features</a></li></ol></li>
	</ol>
	<h2 id="expl">Explanation and rationale for the approach</h2>
	<h3 id="expl.prob">Problem statement</h3>
	<p>The pace of innovation in the standardization of C++ makes long-term stability of
		implementations unlikely. Features are added to the language because programmers
		want to use those features. Features are added to (the working draft of) the standard
		as the features become well-specified. In many cases a feature is added to an implementation
		well before or well after the standard officially introducing it is approved.</p>
	<p>This process makes it difficult for programmers who want to use a feature to know
		whether it is available in any given implementation. Implementations rarely leap
		from one formal revision of the standard directly to the next; the implementation
		process generally proceeds by smaller steps. As a result, testing for a specific
		revision of the standard (e.g. by examining the value of the <code>__cplusplus</code>
		macro) often gives the wrong answer. Implementers generally don't want to appear
		to be claiming full conformance to a standard revision until all of its features
		are implemented. That leaves programmers with no portable way to determine which
		features are actually available to them.</p>
	<p>It is often possible for a program to determine, in a manner specific to a single
		implementation, what features are supported by that implementation; but the means
		are often poorly documented and ad hoc, and sometimes complex &ndash; especially
		when the availability of a feature is controlled by an invocation option. To make
		this determination for a variety of implementations in a single source base is complex
		and error-prone.</p>
	<h3 id="expl.status">Status quo</h3>
	<p>Here is some code that attempts to determine whether rvalue references are available
		in the implementation in use:</p>
	<pre>#ifndef __USE_RVALUE_REFERENCES
  #if (__GNUC__ > 4 || __GNUC__ == 4 &amp;&amp; __GNUC_MINOR__ >= 3) || \
      _MSC_VER >= 1600
    #if __EDG_VERSION__ > 0
      #define __USE_RVALUE_REFERENCES (__EDG_VERSION__ >= 410)
    #else
      #define __USE_RVALUE_REFERENCES 1
    #endif
  #elif __clang__
    #define __USE_RVALUE_REFERENCES __has_feature(cxx_rvalue_references)
  #else
    #define __USE_RVALUE_REFERENCES 0
  #endif
#endif</pre>
	<p>First, the GNU and Microsoft version numbers are checked to see if they are high
		enough. But then a check is made of the EDG version number, since that front end
		also has compatibility modes for both those compilers, and defines macros indicating
		(claimed) compatibility with them. If the feature wasn't implemented in the indicated
		EDG version, it is assumed that the feature is not available &ndash; even though
		it is possible for a customer of EDG to implement a feature before EDG does.</p>
	<p>Fortunately Clang has ways to test specifically for the presence of specific features.
		But unfortunately, the function-call-like syntax used for such tests won't work
		with a standard preprocessor, so this fine new feature winds up adding its own flavor
		of complexity to the mix.</p>
	<p>Also note that this code is only the beginning of a real-world solution. A complete
		solution would need to take into account more compilers, and also command-line option
		settings specific to various compilers.</p>
	<h3 id="expl.soln">Characteristics of the proposed solution</h3>
	<p>To preserve implementers' freedom to add features in the order that makes the most
		sense for themselves and their customers, implementers should indicate the availability
		of each separate feature by adding a definition of a macro with the name corresponding
		to that feature.</p>
	<p><strong>Important note:</strong> By recommending the use of these macros, WG21 is
		<strong>not</strong> making any feature optional; the absence of a definition for
		the relevant feature-test macro does not make an implementation that lacks a feature
		conform to a standard that requires the feature. However, if implementers and programmers
		follow these recommendations, portability of code between real-world implementations
		should be improved.</p>
	<p>To a first approximation, a feature is identified by the WG21 paper in which it is
		specified, and by which it is introduced into the working draft of the standard.
		Not every paper introduces a new feature worth a feature-test macro, but every paper
		that is not just a collection of issue resolutions is considered a candidate; exceptions
		are explicitly justified.</p>
	<p>For C++14, it is preferred for the feature-test macro to be named using some combination
		of words from the title of the paper. In the future, it is hoped that every paper
		will include its own recommendations concerning feature-test macro names.</p>
	<p>The value specified for a feature-test macro is based on the year and month in which
		the feature is voted into the working draft. In a case where a feature is subsequently
		changed in a significant way, but arguably remains the same feature, the value of
		the macro can be changed to indicate the &ldquo;revision level&rdquo; of the specification
		of the feature. However, in most cases it is expected that the presence of a feature
		can be determined by the presence of any non-zero macro value; for example:</p>
	<pre>#if __cpp_binary_literals
int const packed_zero_to_three = 0b00011011;
#else
int const packed_zero_to_three = 0x1B;
#endif</pre>
	<p>To avoid the user's namespace, names of macros for language features are prefixed
		by &ldquo;<code>__cpp_</code>&rdquo;; for library features, by &ldquo;<code>__cpp_lib_</code>&rdquo;.
		A library feature that doesn't introduce a new header is expected to be defined
		by the header(s) that implement the feature.</p>
	<h2 id="recs">Recommendations</h2>
	<h3 id="recs.intro">Introduction</h3>
	<p>For the sake of improved portability between partial implementations of various C++
		standards, WG21 (the ISO technical committee for the C++ programming language) recommends
		that implementers and programmers follow the guidelines in this document concerning
		feature-test macros.</p>
	<p>Implementers who provide a new feature should define a macro with the recommended
		name, in the same circumstances under which the feature is available (for example,
		taking into account relevant command-line options), to indicate the presence of
		support for that feature.</p>
	<p>Programmers who wish to determine whether a feature is available in an implementation
		should base that determination on the state of the macro with the recommended name.
		(The absence of a tested feature may result in a program with decreased functionality,
		or the relevant functionality may be provided in a different way. A program that
		strictly depends on support for a feature can just try to use the feature unconditionally;
		presumably, on an implementation lacking necessary support, translation will fail.)</p>
	<h3 id="recs.hasinc">Testing for the presence of a header: <code>__has_include</code></h3>
	<p>It is impossible for a C++ program to directly, reliably and portably determine whether
		or not a library header is available for inclusion. Conditionally including a header
		requires the use of a configuration macro, whose setting can be determined by a
		configuration-test process at build time (reliable, but less portable), or by some
		other means (often not reliable or portable).</p>
	<p>To solve this general problem, WG21 recommends that implementers provide, and programmers
		use, the <code>__has_include</code> feature.</p>
	<p><em>The following description of this feature is adapted from the Clang 3.4 Language
		Extensions documentation on <code>clang.llvm.org</code>. All references to the related
		<code>__has_include_next</code> feature have been deleted, but otherwise the text
		is verbatim. A more formal description of this feature should be expected in a revision
		of this document for the pre-Chicago mailing.</em></p>
	<div class="boxed">
		<p>Not all development systems have the same include files. The <code>__has_include</code>
			macro allows you to check for the existence of an include file before doing a possibly
			failing <code>#include</code> directive. It must be used as an expression in a <code>
				#if</code> or <code>#elif</code> preprocessing directive.</p>
		<p>The <code>__has_include</code> function-like macro takes a single file name string
			argument that is the name of an include file. It evaluates to 1 if the file can
			be found using the include paths, or 0 otherwise:</p>
		<pre>// Note the two possible file name string formats.
#if __has_include(&quot;myinclude.h&quot;) &amp;&amp; __has_include(&lt;stdint.h&gt;)
# include &quot;myinclude.h&quot;
#endif

// To avoid problem with compilers not having this macro.
#if defined(__has_include) &amp;&amp; __has_include(&quot;myinclude.h&quot;)
# include &quot;myinclude.h&quot;
#endif
</pre>
		<p>To test for this feature, use <code>#if defined(__has_include)</code>.</p>
	</div>
	<h3 id="recs.cpp14">C++14 features</h3>
	<p>The following table itemizes all the changes that were made to the working draft
		for C++14 as specified in a WG21 technical document. (Changes that were made as
		specified in a core or library issue are not included.)</p>
	<p>The table is sorted by the section of the standard primarily affected. The &ldquo;Doc.
		No.&rdquo; column links to the paper itself on the committee web site. The &ldquo;Macro
		Name&rdquo; column links to the relevant portion of the &ldquo;Detailed explanation
		and rationale&rdquo; section of this document.</p>
	<table border="1">
		<thead>
			<tr>
				<th colspan="6">Significant changes to C++14</th>
			</tr>
			<tr>
				<th>Doc. No.</th>
				<th>Title</th>
				<th>Primary Section</th>
				<th>Macro Name</th>
				<th>Value</th>
				<th>Header</th>
			</tr>
		</thead>
		<tbody>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf">N3472</a>
				</td>
				<td>Binary Literals in the C++ Core Language</td>
				<td>2.14</td>
				<td><code>__cpp_binary_literals</code></td>
				<td>201304</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3323.pdf">N3323</a>
				</td>
				<td>A Proposal to Tweak Certain C++ Contextual Conversions</td>
				<td>4</td>
				<td colspan="3"><em><a href="#detail.cpp14.n3323">none</a></em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html">N3648</a>
				</td>
				<!--feedback-->
				<td>Wording Changes for Generalized Lambda-capture</td>
				<td>5.1</td>
				<td><code>__cpp_init_captures</code></td>
				<td>201304</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3649.html">N3649</a>
				</td>
				<!--feedback-->
				<td>Generic (Polymorphic) Lambda Expressions</td>
				<td>5.1</td>
				<td><code>__cpp_generic_lambdas</code></td>
				<td>201304</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html">N3664</a>
				</td>
				<td>Clarifying Memory Allocation</td>
				<td>5.3</td>
				<td colspan="3"><em><a href="#detail.cpp14.n3664">none</a></em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3624.html">N3624</a>
				</td>
				<td>Core Issue 1512: Pointer comparison vs qualification conversions</td>
				<td>5.9, 5.10</td>
				<td colspan="3"><em><a href="#detail.cpp14.n3624">none</a></em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html">N3652</a>
				</td>
				<td>Relaxing constraints on constexpr functions / constexpr member functions and implicit
					const</td>
				<td>5.19, 7.1</td>
				<td><code><a href="#detail.cpp14.n3652">__cpp_constexpr</a></code></td>
				<td>201304</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td rowspan="2"><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html">
					N3638</a></td>
				<!--feedback-->
				<td rowspan="2">Return type deduction for normal functions</td>
				<td rowspan="2">7.1</td>
				<td><code><a href="#detail.cpp14.n3638">__cpp_decltype_auto</a></code></td>
				<td>201304</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td><code><a href="#detail.cpp14.n3638">__cpp_return_type_deduction</a></code></td>
				<td>201304</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html">N3639</a>
				</td>
				<td>Runtime-sized arrays with automatic storage duration</td>
				<td>8.3</td>
				<td><code>__cpp_runtime_arrays</code></td>
				<td>201304</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html">N3653</a>
				</td>
				<td>Member initializers and aggregates</td>
				<td>8.5</td>
				<td><code>__cpp_aggregate_nsdmi</code></td>
				<td>201304</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3667.html">N3667</a>
				</td>
				<td>Drafting for Core 1402</td>
				<td>12.8</td>
				<td colspan="3"><em><a href="#detail.cpp14.n3667">none</a></em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf">N3651</a>
				</td>
				<td>Variable Templates</td>
				<td>14, 14.7</td>
				<td><code>__cpp_variable_templates</code></td>
				<td>201304</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3669.pdf">N3669</a>
				</td>
				<td>Fixing constexpr member functions without const</td>
				<td><em>various</em></td>
				<td colspan="3"><em><a href="#detail.cpp14.n3669">none</a></em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3673.html">N3673</a>
				</td>
				<td>C++ Library Working Group Ready Issues Bristol 2013</td>
				<td><em>various</em></td>
				<td colspan="3"><em><a href="#detail.cpp14.n3673">none</a></em></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3471.html">N3471</a>
				</td>
				<td>Constexpr Library Additions: utilities</td>
				<td>20.2-20.4</td>
				<td rowspan="3"><code><a href="#detail.cpp14.n3471">__cpp_lib_constexpr_functions</a></code>
				</td>
				<td rowspan="3">201210</td>
				<td><code>&lt;utility&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3469.html">N3469</a>
				</td>
				<td>Constexpr Library Additions: chrono</td>
				<td>20.11</td>
				<td><code>&lt;chrono&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3470.html">N3470</a>
				</td>
				<td>Constexpr Library Additions: containers</td>
				<td>23.3</td>
				<td><code>&lt;array&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3658.html">N3658</a>
				</td>
				<!--feedback-->
				<td>Compile-time integer sequences</td>
				<td>20</td>
				<td><code>__cpp_lib_integer_sequence</code></td>
				<td>201304</td>
				<td><code>&lt;utility&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3668.html">N3668</a>
				</td>
				<!--feedback-->
				<td>exchange() utility function</td>
				<td>20</td>
				<td><code>__cpp_lib_exchange_function</code></td>
				<td>201304</td>
				<td><code>&lt;utility&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3670.html">N3670</a>
				</td>
				<td>Wording for Addressing Tuples by Type</td>
				<td>20.2-20.4</td>
				<td><code>__cpp_lib_tuples_by_type</code></td>
				<td>201304</td>
				<td><code>&lt;utility&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html">N3672</a>
				</td>
				<td>A proposal to add a utility class to represent optional objects</td>
				<td>20.5</td>
				<td><code><a href="#detail.cpp14.n3672">__has_include(&lt;optional&gt;)</a></code>
				</td>
				<td>1</td>
				<td><em>predefined</em></td>
			</tr>
			<!--<tr>
				<td><code>__cpp_lib_header_optional</code></td>
				<td>201304</td>
				<td><code>&lt;utility&gt;</code></td>
			</tr>-->
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3656.htm">N3656</a>
				</td>
				<!--feedback-->
				<td>make_unique</td>
				<td>20.7</td>
				<td><code>__cpp_lib_make_unique</code></td>
				<td>201304</td>
				<td><code>&lt;memory&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm">N3421</a>
				</td>
				<!--feedback-->
				<td>Making Operator Functors greater&lt;&gt;</td>
				<td>20.8</td>
				<td><code>__cpp_lib_transparent_operators</code></td>
				<td>201210</td>
				<td><code>&lt;functional&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3462.html">N3462</a>
				</td>
				<!--feedback-->
				<td>std::result_of and SFINAE</td>
				<td>20.9</td>
				<td><code>__cpp_lib_result_of_sfinae</code></td>
				<td>201210</td>
				<td><code>&lt;functional&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3545.pdf">N3545</a>
				</td>
				<td>An Incremental Improvement to integral_constant</td>
				<td>20.9</td>
				<td><code>__cpp_lib_integral_constant_callable</code></td>
				<td>201304</td>
				<td><code>&lt;type_traits&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3655.pdf">N3655</a>
				</td>
				<td>TransformationTraits Redux</td>
				<td>20.9</td>
				<td><code>__cpp_lib_transformation_trait_aliases</code></td>
				<td>201304</td>
				<td><code>&lt;type_traits&gt;</code></td>
			</tr>
			<tr>
				<td rowspan="2"><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3642.pdf">
					N3642</a></td>
				<td rowspan="2">User-defined Literals for Standard Library Types</td>
				<td>20.11</td>
				<td><code><a href="#detail.cpp14.n3642">__cpp_lib_chrono_udls</a></code></td>
				<td>201304</td>
				<td><code>&lt;chrono&gt;</code></td>
			</tr>
			<tr>
				<td>21.7</td>
				<td><code><a href="#detail.cpp14.n3642">__cpp_lib_string_udls</a></code></td>
				<td>201304</td>
				<td><code>&lt;string&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html">N3662</a>
				</td>
				<!--feedback-->
				<td>C++ Dynamic Arrays</td>
				<td>23.2, 23.3</td>
				<td><code><a href="#detail.cpp14.n3672">__has_include(&lt;dynarray&gt;)</a></code>
				</td>
				<td>1</td>
				<td><em>predefined</em></td>
			</tr>
			<!--<tr>
				<td><code>__cpp_lib_header_dynarray</code></td>
				<td>201304</td>
				<td><code>&lt;utility&gt;</code></td>
			</tr>-->
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3657.htm">N3657</a>
				</td>
				<!--feedback-->
				<td>Adding heterogeneous comparison lookup to associative containers</td>
				<td>23.4</td>
				<td><code>__cpp_lib_generic_associative_lookup</code></td>
				<td>201304</td>
				<td><code>&lt;map&gt;</code><br />
					<code>&lt;set&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3644.pdf">N3644</a>
				</td>
				<!--feedback-->
				<td>Null Forward Iterators</td>
				<td>24.2</td>
				<td><code>__cpp_lib_null_iterators</code></td>
				<td>201304</td>
				<td><code>&lt;iterator&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3671.html">N3671</a>
				</td>
				<td>Making non-modifying sequence operations more robust</td>
				<td>25.2</td>
				<td><code>__cpp_lib_robust_nonmodifying_seq_ops</code> </td>
				<td>201304</td>
				<td><code>&lt;algorithm&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3654.html">N3654</a>
				</td>
				<td>Quoted Strings Library Proposal</td>
				<td>27.7</td>
				<td><code>__cpp_lib_quoted_string_io</code></td>
				<td>201304</td>
				<td><code>&lt;iomanip&gt;</code></td>
			</tr>
			<tr>
				<td><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3659.html">N3659</a>
				</td>
				<td>Shared locking in C++</td>
				<td>30.4</td>
				<td><code>__cpp_lib_shared_mutex</code></td>
				<td>201304</td>
				<td><code>&lt;mutex&gt;</code></td>
			</tr>
		</tbody>
	</table>
	<h3 id="recs.cpp11">C++11 features</h3>
	<p><em>STUB: this table should be considered a very rough, preliminary, incomplete draft</em></p>
	<table border="1">
		<thead>
			<tr>
				<th colspan="6">Significant features of C++11</th>
			</tr>
			<tr>
				<th>Doc. No.</th>
				<th>Title</th>
				<th>Primary Section</th>
				<th>Macro name</th>
				<th>Value</th>
				<th>Header</th>
			</tr>
		</thead>
		<tbody>
			<tr>
				<td>N2249</td>
				<td>New Character Types in C++</td>
				<td>2.13</td>
				<td><code>__cpp_unicode_characters</code></td>
				<td>200704</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td rowspan="2">N2442</td>
				<td rowspan="2">Raw and Unicode String Literals Unified Proposal</td>
				<td rowspan="2">2.13</td>
				<td><code>__cpp_raw_strings</code></td>
				<td>200710</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td><code>__cpp_unicode_literals</code></td>
				<td>200710</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td>N2765</td>
				<td>User-defined Literals</td>
				<td>2.13, 13.5</td>
				<td><code>__cpp_user_defined_literals</code></td>
				<td>200809</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td>N2235</td>
				<td>Generalized Constant Expressions</td>
				<td>5.19, 7.1</td>
				<td><code>__cpp_constexpr</code></td>
				<td>200704</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td>N2343</td>
				<td>Decltype</td>
				<td>7.1</td>
				<td><code>__cpp_decltype</code></td>
				<td>200707</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td>N2761</td>
				<td>Towards support for attributes in C++</td>
				<td>7.6</td>
				<td><code>__cpp_attributes</code></td>
				<td>200809</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td>N2118</td>
				<td>A Proposal to Add an Rvalue Reference to the C++ Language</td>
				<td>8.3</td>
				<td><code>__cpp_rvalue_reference</code></td>
				<td>200610</td>
				<td><em>predefined</em></td>
			</tr>
			<tr>
				<td>N2242</td>
				<td>Proposed Wording for Variadic Templates</td>
				<td>8.3, 14</td>
				<td><code>__cpp_variadic_templates</code></td>
				<td>200704</td>
				<td><em>predefined</em></td>
			</tr>
		</tbody>
	</table>
	<h3 id="recs.condsupp">Conditionally-supported constructs</h3>
	<p><em>STUB</em></p>
	<!--
	<p>The standard requires implementations to document the conditionally-supported constructs
		it does <strong>not</strong> support. For consistency, the recommendation is to
		define a macro for each conditionally-supported construct that is diagnosed (not
		supported)</p>
	<table border="1">
		<thead>
			<tr>
				<th>Reference</th>
				<th>Description</th>
				<th>Macro name</th>
			</tr>
		</thead>
		<tbody>
			<tr>
				<td>2.9p2</td>
				<td>The appearance of either of the characters <code>’</code> or <code>\</code> or of
					either of the character sequences <code>/*</code> or <code>//</code> in a <var>q-char-sequence</var>
					or an <var>h-char-sequence</var> is conditionally supported with implementation-defined
					semantics, as is the appearance of the character <code>"</code> in an <var>h-char-sequence</var>.
				</td>
				<td><code>__cond_no_weird_header_names</code></td>
			</tr>
			<tr>
				<td>2.14.3p1</td>
				<td>A multicharacter literal, or an ordinary character literal containing a single <var>
					c-char</var> not representable in the execution character set, is conditionally-supported,
					has type <code>int</code>, and has an implementation-defined value. </td>
				<td><code>__cond_no_multicharacter_literals</code></td>
			</tr>
			<tr>
				<td>2.14.3p3</td>
				<td>Escape sequences in which the character following the backslash is not listed in
					Table 7 are conditionally-supported, with implementation-defined semantics.</td>
				<td><em>Probably no single macro would make sense for this.</em></td>
			</tr>
			<tr>
				<td>2.14.5p13</td>
				<td>Any other concatenations are conditionally supported with implementation-defined
					behavior.</td>
				<td><em>Probably no single macro would make sense for this.</em></td>
			</tr>
			<tr>
				<td>5.2.2p7</td>
				<td>Passing a potentially-evaluated argument of class type (Clause 9) having a nontrivial
					copy constructor, a non-trivial move constructor, or a non-trivial destructor, with
					no corresponding parameter, is conditionally-supported with implementation-defined
					semantics.</td>
				<td><code>__cond_no_passing_non_pod_by_ellipsis</code></td>
			</tr>
			<tr>
				<td>5.2.10p8</td>
				<td>Converting a function pointer to an object pointer type or vice versa is conditionally-supported.
				</td>
				<td><code>__cond_no_fun_obj_ptr_conversion</code></td>
			</tr>
			<tr>
				<td>7.4p1</td>
				<td>The asm declaration is conditionally-supported; its meaning is implementation-defined.
				</td>
				<td><code>__cond_no_asm_declaration</code></td>
			</tr>
			<tr>
				<td>7.5p2</td>
				<td>Use of a <var>string-literal</var> other than <code>"C"</code> or <code>"C++"</code>
					is conditionally-supported, with implementation-defined semantics.</td>
				<td><em>Probably no single macro would make sense for this.</em></td>
			</tr>
			<tr>
				<td>7.6.1p3</td>
				<td>The use of an <var>attribute-scoped-token</var> is conditionally-supported, with
					implementation-defined behavior.</td>
				<td><code>_cond_no_attribute_scoped_token</code></td>
			</tr>
			<tr>
				<td>14p4</td>
				<td>Use of a linkage specification other than C or C++ with any of these constructs
					is conditionally-supported, with implementation-defined semantics.</td>
				<td><code>_cond_no_template_linkage_spec</code></td>
			</tr>
		</tbody>
	</table>
-->
	<h3 id="recs.cpp98">C++98 features</h3>
	<p><em>STUB: especially for exception handling and RTTI</em></p>
	<h2 id="detail">Detailed explanation and rationale</h2>
	<h3 id="detail.cpp14">C++14 features</h3>
	<h4 id="detail.cpp14.n3323">N3323: A Proposal to Tweak Certain C++ Contextual Conversions</h4>
	<p>This paper specifies a small change that is considered to be more of a bug fix than
		a new feature, so no macro is considered necessary.</p>
	<h4 id="detail.cpp14.n3471">N3469: Constexpr Library Additions: chrono<br />
		N3470: Constexpr Library Additions: containers<br />
		N3471: Constexpr Library Additions: utilities</h4>
	<p>These papers specify closely related, textually minor changes to different library
		headers. It is considered unlikely that they would be applied to an implementation
		at different times, so one macro is recommended for all three.</p>
	<h4 id="detail.cpp14.n3624">N3624: Core Issue 1512: Pointer comparison vs qualification
		conversions</h4>
	<p>This paper contained the wording changes to resolve a core issue. It did not introduce
		a new feature, so no macro is considered necessary.</p>
	<h4 id="detail.cpp14.n3638">N3638: Return type deduction for normal functions</h4>
	<p>This paper describes two separate features: the ability to deduce the return type
		of a function from the return statements contained in its body, and the ability
		to use <code>decltype(auto)</code>. These features can be implemented independently,
		so a macro is recommended for each.</p>
	<h4 id="detail.cpp14.n3642">N3642: User-defined Literals for Standard Library Types</h4>
	<p>This paper specifies user-defined literal operators for two different standard library
		types, which could be implemented independently. Furthermore, user-defined literal
		operators are expected to be added later for at least one other library type. So
		for consistency and flexibility, each type is given its own macro.</p>
	<h4 id="detail.cpp14.n3652">N3652: Relaxing constraints on constexpr functions / constexpr
		member functions and implicit const</h4>
	<p>The major change proposed by this paper is considered to be strictly a further development
		of the <code>constexpr</code> feature of C++11. Consequently, the recommendation
		here is to give an increased value to the macro indicating C++11 support for <code>constexpr</code>.</p>
	<h4 id="detail.cpp14.n3662">N3662: C++ Dynamic Arrays</h4>
	<p>We have a long-term solution that uses <code>__has_include</code>. There was not
		sufficient support and a number of objections against adding macros to existing
		library header files, as there was not consensus on a place to put them.</p>
	<!--p>There is a simple workaround for library providers, which is to provide the new header
		as soon as possible, even if all the header does is define the appropriate macro
		to zero.</p-->
	<p>There is also a simple workaround for users that are not using libraries that define
		the header file: supplying their own header that is further down the search path
		than the library headers.</p>
	<h4 id="detail.cpp14.n3664">N3664: Clarifying Memory Allocation</h4>
	<p>The substantive change in this paper just relaxes a restriction on implementations.
		There is no new feature for a programmer to use, so no macro is considered necessary.</p>
	<h4 id="detail.cpp14.n3667">N3667: Drafting for Core 1402</h4>
	<p>This paper contained the wording changes to resolve a core issue. It did not introduce
		a new feature, so no macro is considered necessary.</p>
	<h4 id="detail.cpp14.n3669">N3669: Fixing constexpr member functions without const</h4>
	<p>This paper contained the wording changes to ensure that a minor change proposed by
		N3652 did not impact the standard library. It did not introduce a new feature, so
		no macro is considered necessary.</p>
	<h4 id="detail.cpp14.n3672">N3672: A proposal to add a utility class to represent optional
		objects</h4>
	<p>See <a href="#detail.cpp14.n3662">N3662</a>.</p>
	<h4 id="detail.cpp14.n3673">N3673: C++ Library Working Group Ready Issues Bristol 2013</h4>
	<p>This paper was just a collection of library issues. It did not introduce a new feature,
		so no macro is considered necessary.</p>
</body>
</html>
