SD-6: SG10 Feature Test Recommendations

Doc. No.: SD-6
Date: 2017-10-09
Reply to: Clark Nelson
Title: Feature-testing recommendations for C++
Audience: SG10, EWG, LEWG

Feature-testing recommendations for C++

Preface

At the July 2017 (Toronto) meeting, a poll was taken in EWG:

Do we feel that the plenary should formally approve SD-6 revisions?
4 | 9 | 14 | 4 | 1
Ville: That's 13-5, so there's some feeling that it might be a good idea.

To pursue this idea, it would make sense for EWG and LEWG (for starters) to consider the content of this document, probably more closely than they have in the past.

Contents

  1. Introduction
  2. Explanation and rationale for the approach
    1. Problem statement
    2. Status quo
    3. Characteristics of the proposed solution
  3. Recommendations
    1. Introduction
    2. Testing for the presence of a header: __has_include
    3. Testing for the presence of an attribute: __has_cpp_attribute
    4. C++17 features
    5. C++14 features
    6. C++11 features
    7. C++98 features (STUB)
    8. Features published and later removed
  4. Annex: Recommendations from Technical Specifications
  5. Annex: Detailed explanation and rationale
    1. C++14 features
    2. C++17 features
  6. Annex: Model wording for a Technical Specification
  7. Revision history

Introduction

At the September 2013 (Chicago) meeting of WG21, there was a five-way poll of all of the C++ experts in attendance – approximately 80 – concerning their support for the approach described herein for feature-testing in C++. The results of the poll:

Strongly favor Favor Neutral Oppose Strongly oppose
lots lots 1 0 0

General support for these recommendations was reaffirmed at the 2015 October (Kona) meeting, as indicated by the following straw poll:

Should WG21 encourage, but not require, feature-test macros for proposals?

Strongly favor Favor Neutral Against Strongly against
50 13 7 3 2

This document was subsequently designated WG21's SD-6 (sixth standing document), which will continue to be maintained by SG10.

Explanation and rationale for the approach

Problem statement

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.

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 __cplusplus 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.

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 – 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.

Status quo

Here is some code that attempts to determine whether rvalue references are available in the implementation in use:

#ifndef __USE_RVALUE_REFERENCES
  #if (__GNUC__ > 4 || __GNUC__ == 4 && __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

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 – even though it is possible for a customer of EDG to implement a feature before EDG does.

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.

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.

Characteristics of the proposed solution

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.

Important note: By recommending the use of these macros, WG21 is not 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.

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.

For C++14, the feature-test macro name generally consists of 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.

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 is changed to indicate the “revision level” 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:

template<typename T>
struct use_empty_base_opt :
	std::integral_constant<bool, 
		std::is_empty<T>::value
#if __cpp_lib_is_final
		&& !std::is_final<T>::value
#endif
	>
{ };

To avoid the user's namespace, names of macros for language features are prefixed by “__cpp_”; for library features, by “__cpp_lib_”. A library feature that doesn't introduce a new header is expected to be defined by the header(s) that implement the feature.

Recommendations

Introduction

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.

Implementers who provide a new standard feature should define a macro with the recommended name and value, 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.

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. Therefore, if the most useful purpose for a feature-test macro would be to control the inclusion of a #error directive if the feature is unavailable, that is considered inadequate justification for the macro. Note that the usefulness of a test macro for a feature is completely independent of the usefulness of the feature itself.)

Testing for the presence of a header: __has_include

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).

To solve this general problem, WG21 recommends that implementers provide, and programmers use, the __has_include feature.

Syntax

h-preprocessing-token:
any preprocessing-token other than >
h-pp-tokens:
h-preprocessing-token
h-pp-tokens h-preprocessing-token
has-include-expression:
__has_include ( header-name )
__has_include ( string-literal )
__has_include ( < h-pp-tokens > )

Semantics

In the first form of the has-include-expression, the parenthesized header-name token is not subject to macro expansion. The second and third forms are considered only if the first form does not match, and the preprocessing tokens are processed just as in normal text.

A has-include-expression shall appear only in the controlling constant expression of a #if or #elif directive ([cpp.cond] 16.1). Prior to the evaluation of such an expression, the source file identified by the parenthesized preprocessing token sequence in each contained has-include-expression is searched for as if that preprocessing token sequence were the pp-tokens in a #include directive, except that no further macro expansion is performed. If such a directive would not satisfy the syntactic requirements of a #include directive, the program is ill-formed. The has-include-expression is replaced by the pp-number 1 if the search for the source file succeeds, and by the pp-number 0 if the search fails.

The #ifdef and #ifndef directives, and the defined conditional inclusion operator, shall treat __has_include as if it were the name of a defined macro. The identifier __has_include shall not appear in any context not mentioned in this section.

Example

This demonstrates a way to use a library optional facility only if it is available.

#ifdef __has_include
#  if __has_include(<optional>)
#    include <optional>
#    define have_optional 1
#  elif __has_include(<experimental/optional>)
#    include <experimental/optional>
#    define have_optional 1
#    define experimental_optional
#  else
#    define have_optional 0
#  endif
#endif

Testing for the presence of an attribute: __has_cpp_attribute

A C++ program cannot directly, reliably, and portably determine whether or not a standard or vendor-specific attribute is available for use. Testing for attribute support generally requires complex macro logic, as illustrated above for language features in general.

To solve this general problem, WG21 recommends that implementers provide, and programmers use, the __has_cpp_attribute feature.

Syntax

has-attribute-expression:
__has_cpp_attribute ( attribute-token )

Semantics

A has-attribute-expression shall appear only in the controlling constant expression of a #if or #elif directive ([cpp.cond] 16.1). The has-attribute-expression is replaced by a non-zero pp-number if the implementation supports an attribute with the specified name, and by the pp-number 0 otherwise.

For a standard attribute, the value of the __has_cpp_attribute macro is based on the year and month in which the attribute was voted into the working draft. In the case where the attribute is vendor-specific, the value is implementation-defined. However, in most cases it is expected that the availability of an attribute can be detected by any non-zero result.

The #ifdef and #ifndef directives, and the defined conditional inclusion operator, shall treat __has_cpp_attribute as if it were the name of a defined macro. The identifier __has_cpp_attribute shall not appear in any context not mentioned in this section.

Example

This demonstrates a way to use the attribute [[deprecated]] only if it is available.

#ifndef __has_cpp_attribute
# define __has_cpp_attribute(x) 0
#endif
#ifdef __has_cpp_attribute
#if __has_cpp_attribute(deprecated)
# define ATTR_DEPRECATED(msg) [[deprecated(msg)]]
#else
# define ATTR_DEPRECATED(msg)
#endif
#endif

C++17 features

The following table itemizes all the changes that were made to the working draft for C++17 as specified in a WG21 technical document. (Changes that were made as specified in a core or library issue are not generally included.)

The table is sorted by the section of the standard primarily affected. The “Doc. No.” column links to the paper itself on the committee web site. The “Macro Name” column links to the relevant portion of the “Detailed explanation and rationale” annex of this document. When the recommendation is to change the value of a macro previously recommended to be defined, the “Value” column links to the table entry for the previous recommendation.

For library features, the “Header“ column identifies the header that is expected to define the macro, although the macro may also be predefined. For language features, the macro must be predefined.

Significant changes to C++17
Doc. No. Title Primary Section Macro Name Value Header
P0296R2 Forward progress guarantees: Base definitions 4.7 none
P0299R1 Forward progress guarantees for the Parallelism TS features 4.7, 28.4 none
N4086 Removing trigraphs??! 5 none
P0245R1 Hexadecimal floating literals for C++ 5.13 __cpp_hex_float ex. 201603 predefined
N4267 Adding u8 character literals 5.13 none
P0386R2 Inline Variables 6.2, 10.1 __cpp_inline_variables 201606 predefined
P0035R4 Dynamic memory allocation for over-aligned data 6.7, 8.3, 21.6 __cpp_aligned_new ex. 201606 predefined
P0135R1 Wording for guaranteed copy elision through simplified value categories 6.10 __cpp_guaranteed_copy_elision 201606 predefined
N4261 Proposed resolution for Core Issue 330: Qualification conversions and pointers to arrays of pointers 7.5, 8.2 none
P0012R1 Make exception specifications be part of the type system 7.13, 18.4 __cpp_noexcept_function_type ex. 201510 predefined
P0145R3 Refining Expression Evaluation Order for Idiomatic C++ 8 none
N4295 Folding expressions 8.1, 17.6 __cpp_fold_expressions 201411 predefined
P0018R3 Lambda Capture of *this by Value as [=,*this] 8.1 __cpp_capture_star_this ex. 201603 predefined
P0170R1 Wording for Constexpr Lambda 8.1 __cpp_constexpr 201603 predefined
P0002R1 Remove Deprecated operator++(bool) 8.3 none
P0292R2 constexpr if: A slightly different syntax 9.4 __cpp_if_constexpr ex. 201606 predefined
P0305R1 Selection statements with initializer 9.4 none
P0184R0 Generalizing the Range-Based For Loop 9.5 __cpp_range_based_for 201603 predefined
N3928 Extending static_assert 10 __cpp_static_assert 201411 predefined
N3922 New Rules for auto deduction from braced-init-list 10.1 none
P0001R1 Remove Deprecated Use of the register Keyword 10.1 none
P0091R3 Template argument deduction for class templates 10.1, 16.3, 17.9 __cpp_deduction_guides ex. 201606 predefined
P0512R0 Class Template Argument Deduction Assorted NB resolution and issues 16.3, 17.9 __cpp_deduction_guides ex. 201611 predefined
P0127R2 Declaring non-type template parameters with auto 10.1, 17.8 __cpp_nontype_template_parameter_auto ex. 201606 predefined
N4266 Attributes for namespaces and enumerators 10.2, 10.3 __cpp_namespace_attributes 201411 predefined
__cpp_enumerator_attributes 201411 predefined
N4230 Nested namespace definition 10.3 none
P0136R1 Rewording inheriting constructors (core issue 1941 et al) 10.3, 15.6 __cpp_inheriting_constructors ex. 201511 predefined
P0195R2 Pack expansions in using-declarations 10.3 __cpp_variadic_using 201611 predefined
P0188R1 Wording for [[fallthrough]] attribute 10.6 __has_cpp_attribute(fallthrough) 201603 predefined
P0189R1 Wording for [[nodiscard]] attribute 10.6 __has_cpp_attribute(nodiscard) 201603 predefined
P0212R1 Wording for [[maybe_unused]] attribute 10.6 __has_cpp_attribute(maybe_unused) 201603 predefined
P0028R4 Using attribute namespaces without repetition 10.6 none
P0283R2 Standard and non-standard attributes 10.6 none
P0217R3 Proposed wording for structured bindings 11.5 __cpp_structured_bindings ex. 201606 predefined
P0017R1 Extension to aggregate initialization 11.6 __cpp_aggregate_bases ex. 201603 predefined
P0138R2 Construction Rules for enum class Values 11.6 none
P0398R0 Core issue 1518: Explicit default constructors and copy-list-initialization 11.6 none
P0134R0 Introducing a name for brace-or-equal-initializers for non-static data members 12.2 none
P0391R0 Introducing the term "templated entity" 17 none
N4051 Allow typename in a template template parameter 17.1 none
N4268 Allow constant evaluation for all non-type template arguments 17.3 __cpp_nontype_template_args 201411 predefined
P0522R0 Matching of template template-arguments excludes compatible templates 17.3 __cpp_template_template_args ex. 201611 predefined
P0036R0 Unary Folds and Empty Parameter Packs 17.6 __cpp_fold_expressions 201603 predefined
N4262 Wording for Forwarding References 17.9 none
N4285 Cleanup for exception-specification and throw-expression 18 none
P0003R5 Removing Deprecated Exception Specifications from C++17 18.4 none
P0061R1 __has_include for C++17 19.1 __has_include defined predefined
P0063R3 C++17 should refer to C11 instead of C99 20.5  none
P0180R2 Reserve a New Library Namespace Future Standardization 20.5 none
P0175R1 Synopses for the C library 21 etc. none
P0298R3 A byte type definition 21.2 __cpp_lib_byte ex. 201603 <cstddef>
P0154R1 constexpr std::hardware_{constructive,destructive}_interference_size 21.6 __cpp_lib_hardware_interference_size ex. 201703 <new>
P0137R1 Core Issue 1776: Replacement of class objects containing reference members 21.6, 4.5 __cpp_lib_launder ex. 201606 <new>
N4259 Wording for std::uncaught_exceptions 21.8 __cpp_lib_uncaught_exceptions 201411 <exception>
N4190 Removing auto_ptr, random_shuffle(), And Old <functional> Stuff 23 none
P0007R1 Constant View: A proposal for a std::as_const helper function template 23.2 __cpp_lib_as_const ex. 201510 <utility>
N4387 Improving pair and tuple 23.4, 23.5 none
P0209R2 make_from_tuple: apply for construction 23.5 __cpp_lib_make_from_tuple ex. 201606 <tuple>
P0220R1 Adopt Library Fundamentals V1 TS Components for C++17 23.5 __cpp_lib_apply ex. 201603 <tuple>
23.6 __has_include(<optional>) 1 predefined
__cpp_lib_optional 201603 <optional>
23.8 __has_include(<any>) 1 predefined
__cpp_lib_any 201603 <any>
23.12 __has_include(<memory_resource>) 1 predefined
__cpp_lib_memory_resource 201603 <memory_resource>
23.14 __cpp_lib_boyer_moore_searcher ex. 201603 <functional>
24.4 __has_include(<string_view>) 1 predefined
__cpp_lib_string_view 201603 <string_view>
28.6 __cpp_lib_sample ex. 201603 <algorithm>
P0032R3 Homogeneous interface for variant, any and optional 23.6-8 __lib_cpp_any ex. 201606 <any>
__lib_cpp_optional ex. 201606 <optional>
P0307R2 Making Optional Greater Equal Again 23.6 __cpp_lib_optional 201606 <optional>
P0088R3 Variant: a type-safe union for C++17 23.7 __has_include(<variant>) 1 predefined
__cpp_lib_variant ex. 201606 <variant>
P0393R3 Making Variant Greater Equal 23.7 none
LWG2296 std::addressof should be constexpr 23.10 __cpp_lib_addressof_constexpr 201603 <memory>
P0040R3 Extending memory management tools 23.10 __cpp_lib_raw_memory_algorithms 201606 <memory>
P0174R2 Deprecating Vestigial Library Parts in C++17 23.10, 27.3 none
P0074R0 Making std::owner_less more flexible 23.11 __cpp_lib_transparent_operators 201510 <memory> <functional>
N4089 Safe conversions in unique_ptr<T[]> 23.11 none
N4366 LWG 2228: Missing SFINAE rule in unique_ptr templated assignment 23.11 none
P0033R1 Re-enabling shared_from_this 23.11 __cpp_lib_enable_shared_from_this 201603 <memory>
P0163R0 shared_ptr::weak_type 23.11 __cpp_lib_shared_ptr_weak_type 201606 <memory>
P0497R0 Fixes to shared_ptr support for arrays 23.11 __cpp_lib_shared_ptr_arrays ex. 201611 <memory>
P0337R0 Delete operator= for polymorphic_allocator 23.12 none
N4169 A proposal to add invoke function template 23.14 __cpp_lib_invoke 201411 <functional>
N4277 TriviallyCopyable reference_wrapper 23.14 none
P0005R4 Adopt not_fn from Library Fundamentals 2 for C++17 23.14 __cpp_lib_not_fn ex. 201603 <functional>
P0358R1 Fixes for not_fn 23.14 none
P0253R1 Fixing a design mistake in the searchers interface in Library Fundamentals 23.14 none
P0302R1 Removing Allocator Support in std::function 23.14 none
N3911 TransformationTrait Alias void_t 23.15 __cpp_lib_void_t 201411 <type_traits>
N4389 Wording for bool_constant 23.15 __cpp_lib_bool_constant 201505 <type_traits>
P0006R0 Adopt Type Traits Variable Templates from Library Fundamentals TS for C++17 23.15 __cpp_lib_type_trait_variable_templates ex. 201510 <type_traits>
P0013R1 Logical Operator Type Traits 23.15 __cpp_lib_logical_traits 201510 <type_traits>
P0185R1 Adding [nothrow-]swappable traits 23.15 __cpp_lib_is_swappable 201603 <type_traits>
P0604R0 Resolving GB 55, US 84, US 85, US 86 23.15 __cpp_lib_is_invocable ex. 201703 <type_traits>
P0258R2 has_unique_object_representations - wording 23.15 __cpp_lib_has_unique_object_representations ex. 201606 <type_traits>
LWG2911 An is_aggregate type trait is needed 23.15 __cpp_lib_is_aggregate ex. 201703 <type_traits>
P0092R1 Polishing <chrono> 23.17 __cpp_lib_chrono ex. 201510 <chrono>
P0505R0 Wording for GB 50 23.17 __cpp_lib_chrono ex. 201611 <chrono>
P0024R2 The Parallelism TS Should be Standardized 23.19 __has_include(<execution>) 1 predefined
__lib_cpp_execution 201603 <execution>
28, 29 __cpp_lib_parallel_algorithm ex. 201603 <algorithm> <numeric>
P0336R1 Better Names for Parallel Execution Policies in C++17 23.19 none
P0067R5 Elementary string conversions 23.20 __cpp_lib_to_chars ex. 201611 <utility>
P0254R2 Integrating std::string_view and std::string 24.3, 24.4 __cpp_lib_string_view 201606 <string> <string_view>
P0272R1 Give 'std::string' a non-const '.data()' member function 24.3 none
P0618R0 Deprecating <codecvt> 25.4 none
N4258 Cleaning-up noexcept in the Library 26.3-26.5, 24.3 __cpp_lib_allocator_traits_is_always_equal 201411 <memory> <scoped_allocator>
<string> <deque>
<forward_list> <list>
<vector> <map>
<set> <unordered_map>
<unordered_set>
N4510 Minimal incomplete type support for standard containers 26.3, 20.5 __cpp_lib_incomplete_container_elements ex. 201505 <forwardlist>
<list> <vector>
P0084R2 Emplace Return Type 26.3 none
N4279 Improved insertion interface for unique-key maps 26.4 __cpp_lib_map_try_emplace 201411 <map>
26.5 __cpp_lib_unordered_map_try_emplace 201411 <unordered_map>
P0083R3 Splicing Maps and Sets 26.2 __cpp_lib_node_extract 201606 <map> <set> <unordered_map> <unordered_set>
N4284 Contiguous Iterators 27.2 none
P0031R0 A Proposal to Add Constexpr Modifiers to reverse_iterator, move_iterator, array and Range Access 27.3 __cpp_lib_array_constexpr ex. 201603 <iterator> <array>
N4280 Non-member size() and more 27.8 __cpp_lib_nonmember_container_access 201411 <iterator> <array> <deque> <forward_list>
<list> <map> <regex> <set> <string>
<unordered_map> <unordered_set> <vector>
P0394R4 Hotel Parallelifornia: terminate() for Parallel Algorithms Exception Handling 28.4, 21.8 none
P0025R0 An algorithm to "clamp" a value between a pair of boundary values 28.7 __cpp_lib_clamp ex. 201603 <algorithm>
P0346R1 A <random> Nomenclature Tweak 29.6 none
P0295R0 Adopt Selected Library Fundamentals V2 Components for C++17 29.8 __cpp_lib_gcd_lcm ex. 201606 <numeric>
P0030R1 Proposal to Introduce a 3-Argument Overload to std::hypot 29.9 __cpp_lib_hypot ex. 201603 <cmath>
P0226R1 Mathematical Special Functions for C++17 29.9 __cpp_lib_math_special_functions ex. 201603 <cmath>
P0218R1 Adopt the File System TS for C++17 30.10 __has_include(<filesystem>) 1 predefined
__cpp_lib_filesystem ex. 201603 <filesystem>
P0219R1 Relative Paths for Filesystem 30.10 __cpp_lib_filesystem 201606 <filesystem>
P0392R0 Adapting string_view by filesystem paths 30.10 __cpp_lib_filesystem 201606 <filesystem>
P0317R1 Directory Entry Caching for Filesystem 30.10 __cpp_lib_filesystem 201703 <filesystem>
P0371R1 Temporarily discourage memory_order_consume 32.4 none
P0152R1 constexpr atomic<T>::is_always_lock_free 32.6  __cpp_lib_atomic_is_always_lock_free ex. 201603 <atomic>
N4508 A proposal to add shared_mutex (untimed) 33.4 __cpp_lib_shared_mutex ex. 201505 <shared_mutex>
P0156R0 Variadic lock_guard 30.4 __cpp_lib_lock_guard_variadic 201510 <thread>
P0156R2 Variadic lock_guard (Rev. 5) 33.4 __cpp_lib_scoped_lock ex. 201703 <mutex>
P0004R1 Remove Deprecated iostreams aliases D none

C++14 features

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 generally included.)

The table is sorted by the section of the standard primarily affected. The “Doc. No.” column links to the paper itself on the committee web site. The “Macro Name” column links to the relevant portion of the “Detailed explanation and rationale” annex of this document. When the recommendation is to change the value of a macro previously recommended to be defined, the “Value” column links to the table entry for the previous recommendation.

For library features, the “Header“ column identifies the header that is expected to define the macro, although the macro may also be predefined. For language features, the macro must be predefined.

Significant changes to C++14
Doc. No. Title Primary Section Macro Name Value Header
N3910 What can signal handlers do? (CWG 1441) 1.9-1.10 none
N3927 Definition of Lock-Free 1.10 none
N3472 Binary Literals in the C++ Core Language 2.14 __cpp_binary_literals 201304 predefined
N3781 Single-Quotation-Mark as a Digit Separator 2.14 none
N3323 A Proposal to Tweak Certain C++ Contextual Conversions 4 none
N3648 Wording Changes for Generalized Lambda-capture 5.1 __cpp_init_captures 201304 predefined
N3649 Generic (Polymorphic) Lambda Expressions 5.1 __cpp_generic_lambdas 201304 predefined
Back to Top