::operator newhas a library provided definition (related to P2013R3).
Users of freestanding implementations would like to be able to detect which library facilities are available for use. With the C++20 feature-test macros, all the feature-test macros are required to be defined in both freestanding and hosted implementations, even when the associated hosted facilities are not available. This paper will make the presence of feature-test macros for hosted facilities implementation-defined.
This paper also clarifies that freestanding implementations need not stop at the bare minimum support for freestanding. Freestanding implementations may provide additional facilities from the standard library, so long as those facilities meet the associated hosted requirements.
This paper grants implementations the freedom to include more than just the facilities that are marked
There will be platforms where, for example, floating point is both available and frequently used (e.g. GPU environments).
On those platforms, it is desirable for implementations to provide many of the facilities in the
We must be careful here though, as we don't want to allow divergence of implementation, and we want to be able to add facilities to the required subset of freestanding.
To permit both vendor extension and future freestanding growth, this paper will require that additionally included facilities must meet the same requirements as for a hosted implementation, with a few exceptions.
Freestanding implementations may include additional macros and namespace scoped entities, beyond what is required in a minimal freestanding implementation.
A freestanding implementation does not need to provide the entirety of a header.
If a freestanding implementation supplies an additional class, the entirety of the class must be present and meet all the hosted requirements.
This prevents some useful vendor extensions, notably
optional, and similarly partial
This does not prevent us from standardizing a partial class in the future, though it does prevent us from getting usage experience in a conforming implementation.
Freestanding implementations may make the use of any non-freestanding, namespace scoped function or function template ill-formed (e.g. generally by marking it
=delete). The intent is to allow the freestanding implementation to control overload resolution, so that a library that works with a freestanding implementation will have the same semantics in a hosted implementation.
Users will be able to rely on the freestanding portions of the standard library. The freestanding portions have portable semantics, and are required to be present. Users may then decide to rely on implementation-defined additions. WG21 will be able to add hosted entities to the freestanding subset without fear of breaking implementation-defined additions, because the implementation-defined additions needed to meet the hosted requirements.
P2013R3 makes the default allocating
::operator news optional.
Users may want to detect this in their code so that they can fall-back to a fixed capacity container rather than a dynamically sized container.
Some users may also want to (ab)use such a feature-test macro so that they can provide an
::operator new implementation when one is not provided by the standard library.
This paper recommends a macro to detect the presence of
::operator new definitions:
Unlike other feature-test macros, this macro will be required to be set to
0 on freestanding implementations that do not provide useful
::operator new definitions.
This will allow users to detect whether the library is an old standard library or a new standard library as well.
Unlike other feature-test macros, this macro will need normative wording to tie the feature-test macro to the feature that it is describing.
C++20 requires that all implementations (freestanding and hosted) define all of the library feature-test macros in the
<version> header, even the feature-test macros that correspond to facilities not required to be present in freestanding implementations.
This means that those feature-test macros provide misleading results on freestanding implementations.
This isn't just a theoretical problem.
Existing implementations are already deploying
<version> headers that report support for
std::chrono facilities, and many others, even though those feature-test macros indicate support for features that require the support of an operating system.
In order for users of freestanding implementations to be able to detect extensions of freestanding, the users need a way of distinguishing the C++20 macro requirements from an accurate expression of extension.
This paper will provide a new macro,
__cpp_lib_freestanding_feature_test_macros, so that users can distinguish between these cases.
__cpp_lib_freestanding_feature_test_macros is present, users will know that the C++20 feature-test macros aren't lying.
<version>header are not required to be present on freestanding implementations. The corresponding facilities were either required to be present in C++20, or are added in P1642.
Users of freestanding implementations will want to know whether including a formerly hosted-only header will work or not. Users of freestanding implementations will also what to know if all the facilities that are required to be in freestanding have been made available yet. This is a concern for highly portable libraries, and for users that need to support old and new compilers.
These feature-test macros are provided at a per-header granularity.
This enables implementations to advertise new capabilities more easily than a single feature-test macro for the entirety of this paper.
This also follows the precedent set by the
If new, pre-C++20 functionality is added to the freestanding subset of C++, then the respective feature-test macro for the header should be bumped. If the functionality is new in C++23 or later, then alternative approaches should be taken. These alternative approaches are discussed in the examples section.
The following, existing feature-test macros cover some features that I am making freestanding, and some features that I am not requiring to be freestanding.
These feature-test macros won't be required in freestanding, as they could cause substantial confusion when the hosted parts of those features aren't available.
__cpp_lib_freestanding_* macros should provide a suitable replacement in freestanding environments.
default_searcheris in, other searchers require the heap.
constexprification of various memory algorithms is in, anything dealing with
__cpp_lib_ranges: stream iterators are out
__cpp_lib_raw_memory_algorithms: ExecutionPolicy overloads are out
This paper patches up many of the historical problems with freestanding and feature-test macros. The following are the guidelines I recommend to keep feature-test macros useful for freestanding in the future.
__cpp_lib_foowill cover the full paper in the hosted case, and
__cpp_lib_freestanding_foowill cover the freestanding portions.
__cpp_lib_freestanding_foo. Define the macro to 0 when the feature is not present, and add normative wording tying the feature to the feature test macro.
#if (__STDC_HOSTED__ || \ (defined(__cpp_lib_freestanding_feature_test_macros) && \ __cpp_lib_freestanding_feature_test_macros >= 202112)) #define TRUTHFUL_MACROS 1 #else #define TRUTHFUL_MACROS 0 #endif
#if TRUTHFUL_MACROS && defined(__cpp_lib_filesystem) && __cpp_lib_filesystem >= 201703L // hosted and freestanding extension success path #else // fallback path #endif
#if TRUTHFUL_MACROS && defined(__cpp_lib_ssize) && __cpp_lib_ssize >= 201902L // hosted and freestanding success path #else // fallback path #endif
#if TRUTHFUL_MACROS && defined(__cpp_lib_raw_memory_algorithms) && __cpp_lib_raw_memory_algorithms >= 201606L // hosted and freestanding extension success path #elif defined(__cpp_lib_freestanding_memory) && __cpp_lib_freestanding_memory >= 202007L // freestanding success path #else // fallback path #endif
#if defined(__cpp_lib_freestanding_tuple) && __cpp_lib_freestanding_tuple >= 202007L // freestanding and future hosted success path #elif __STDC_HOSTED__ // flakey hosted success path. Assume tuple works here #else // fallback path #endif
// No good answers here. Currently calling this out of scope.
#if defined(__cpp_lib_always_freestanding_feature) && __cpp_lib_always_freestanding_feature >= 202202L // hosted and freestanding success path #else // fallback path #endif
#if defined(__cpp_lib_eventually_freestanding_feature) #if __cpp_lib_eventually_freestanding_feature >= 202702L // freestanding success path. Will also trigger for new hosted toolchains #elif __STDC_HOSTED__ && __cpp_lib_eventually_freestanding_feature >= 202102L // Interim hosted success path #else // Interim freestanding fallback path #endif #else // fallback path #endif // Alternative that will work 99% of the time #if defined(__cpp_lib_eventually_freestanding_feature) // freestanding and hosted success, probably #else // fallback path #endif
__cpp_lib_foofor the full paper, and
__cpp_lib_freestanding_foofor the freestanding portion.
#if defined(__cpp_lib_freestanding_foo) && __cpp_lib_freestanding_foo >= 202202L // hosted and freestanding success path #else // fallback path #endif
__cpp_lib_freestanding_barfor the freestanding portion.
#if defined(__cpp_lib_bar) && __cpp_lib_bar >= 202202L // Old hosted toolchain path and freestanding extension path #elif defined(__cpp_lib_freestanding_bar) && __cpp_lib_freestanding_bar >= 202702L // freestanding success path. Will also trigger for new hosted toolchains #else // fallback path #endif
::operator new's definition in the standard library?
#if defined(__cpp_lib_freestanding_operator_new) #if __cpp_lib_freestanding_operator_new >= 202009L // ::operator new is available #else // No ::operator new available static_assert(__cpp_lib_freestanding_operator_new == 0) #endif #elif (/*vendor specific test*/) // old, non-conforming freestanding "success" path. No ::operator new available. #else // old hosted and heap-capable freestanding code path. ::operator new is available. #endif
Users need a bit of information to know whether the C++20 macros are lying or not. Prior revisions of this paper provided that bit by bumping the version number of the C++20 macros. This works, but it expands the scope of this change. It also interacts poorly when there are multiple changes to the same macro.
Instead, we provide the bit of information with the new
Allowing partial classes gives implementers a great deal of freedom to experiment and to provide extensions.
It also permits abuse by the implementers.
On the positive side, an implementation could provide
This helps replace C facilities with better facilities from C++.
On the negative side, an implementation could
=delete the copy constructor.
Removing the wrong functions would also mean that a class may not satisfy the same concepts in hosted vs. freestanding.
Rather than have a
__cpp_lib_freestanding_ratio (for example), we could instead update
Users could test the value of
__cpp_lib_chrono to determine if it is freestanding safe or not.
There are at least two big flaws with this approach.
First, not all facilities (particularly older ones) have existing feature-test macros to bump (e.g.
Users would still like to be able to detect the availability of the features in freestanding.
Second, implementers don't always implement features in the same order that they are added to the working draft.
If a new feature were added to the
<chrono> header that necessitated a feature-test macro bump, and an implementer addressed that feature before making the
<ratio> header freestanding safe, then the implementer would either need to stick with the pre-freestanding feature-test macro version, or provide a misleading feature-test macro version.
Rather than introduce a feature-test macro per header in this paper, I could instead introduce one feature-test macro... perhaps
__cpp_lib_freestanding. Each paper that adds old facilities to freestanding could then introduce it's own macro, or bump the old one.
This approach can work, but it restricts the order in which implementers can meaningfully implement freestanding features. All of the old paper needs to be done before any of the old paper's progress can be advertised. All of the old paper needs to be done before advertising any newer papers.
This paper could choose to add a feature-test macro for
There would be some value to users in that they could express exactly what it is they need, and see if that very specific facility is available.
However, this approach is an implementation hassle, and prone to endless wg21 debates on how to partition and name the facilities. Grouping facilities by header provides a natural partitioning and naming scheme.
Some have suggested using
__has_include to detect whether the
<tuple> header (for example) is usable on a particular freestanding implementation.
This doesn't work in practice for multiple reasons.
<iterator>header. In older versions of Visual Studio, a user could attempt to
#include <iterator>. The streaming iterators in the header result in compiler errors. We need feature-test macros to indicate whether including the header is well-formed. The second example is headers that do standard versions checks inside. The libstdc++ implementation of the
<ranges>header is mostly empty if the language version is less than C++20.
__has_includewill still report the header as present though.
__cpp_lib_freestanding_*macros freestanding only
This complicates the client feature-test code for features that were marked freestanding in their initial papers. It doesn't make any of the client feature-test code any simpler. It also violates the principle that freestanding should be a subset of hosted.
__cpp_lib_freestanding_*macros to 0 in hosted
Users of the freestanding macros would still need to account for the case where the macro isn't present.
Defining the macro to zero doesn't provide any information beyond what
We could define a feature-test macro in the negative, for example
This would be different from every other feature-test macro in the standard and SD-6 (SD-6's
__cpp_exceptions are defined in the positive).
Hosted implementations would never define this macro.
Freestanding implementations may or may not define the macro.
When the user detects this "absence" macro, they could take action confidently.
When a user fails to detect a "presence" macro, the user would need to carefully consider whether it is because of an old standard library or a missing
::operator new definition.
This approach would still be useful "soon", but it would leave the ambiguity of the pre-adoption and post-adoption states.
We could have a "presence" feature-test macro that is undefined when not set, as opposed to set to
0, as is proposed.
Unfortunately, it would take a long time for this macro to be useful in practice.
Most implementations today have an
::operator new definition available, but don't have this macro defined.
That means that this macro would only be useful in the distant future, where the absence of this macro is more likely to indicate a system without a heap than a system with an old standard library.
Setting the macro to
0 when the feature is not present is critical to the usability.
The following wording is relative to N4901, and assumes that P1642 and P2013 have been applied.
Please append the following paragraphs to [compliance].
The hosted library facilities are the set of facilities described in this document that are required for hosted implementations, but not required for freestanding implementations.A freestanding implementation provides a (possibly empty) implementation-defined subset of the hosted library facilities.Unless otherwise specified, the requirements on each macro and namespace scoped entity provided in this way shall be the same as the corresponding requirements in a hosted implementation.A freestanding implementation provides deleted definitions for a (possibly empty) implementation-defined subset of the namespace scoped functions and function templates from the hosted library facilities.[ Note: An implementation may provide a deleted definition so that overload resolution does not silently change when migrating a library from a freestanding implementation to a hosted implementation. -end note]
Please make the following changes to [version.syn]. Use the current year-based constant instead of "new-val".
#define __cpp_lib_addressof_constexpr 201603L // also in <memory> #define __cpp_lib_allocate_at_least 202106L // also in <memory> #define __cpp_lib_allocator_traits_is_always_equal 201411L // also in <memory>, <scoped-allocator>, <string>, <deque>, <forward-list>, <list>, <vector>, // <map>, <set>, <unordered-map>, <unordered-set> #define __cpp_lib_adaptor_iterator_pair_constructor 202106L // also in <stack>, <queue> #define __cpp_lib_any 201606L // also in <any> #define __cpp_lib_apply 201603L // also in <tuple> #define __cpp_lib_array_constexpr 201811L // also in <iterator>, <array> #define __cpp_lib_as_const 201510L // also in <utility> #define __cpp_lib_associative_heterogeneous_erasure 202110L // also in <map>, <set>, <unordered_map>, <unordered_set> #define __cpp_lib_assume_aligned 201811L // also in <memory> #define __cpp_lib_atomic_flag_test 201907L // also in <atomic> #define __cpp_lib_atomic_float 201711L // also in <atomic> #define __cpp_lib_atomic_is_always_lock_free 201603L // also in <atomic> #define __cpp_lib_atomic_lock_free_type_aliases 201907L // also in <atomic> #define __cpp_lib_atomic_ref 201806L // also in <atomic> #define __cpp_lib_atomic_shared_ptr 201711L // also in <memory> #define __cpp_lib_atomic_value_initialization 201911L // also in <atomic>, <memory> #define __cpp_lib_atomic_wait 201907L // also in <atomic> #define __cpp_lib_barrier 201907L // also in <barrier> #define __cpp_lib_bind_front 201907L // also in <functional> #define __cpp_lib_bit_cast 201806L // also in <bit> #define __cpp_lib_bitops 201907L // also in <bit> #define __cpp_lib_bool_constant 201505L // also in <type-traits> #define __cpp_lib_bounded_array_traits 201902L // also in <type-traits> #define __cpp_lib_boyer_moore_searcher 201603L // also in <functional> #define __cpp_lib_byte 201603L // also in <cstddef> #define __cpp_lib_byteswap 202110L // also in <bit> #define __cpp_lib_char8_t 201907L // also in <atomic>, <filesystem>, <istream>, <limits>, <locale>, <ostream>, <string>, <string-view> #define __cpp_lib_chrono 201907L // also in <chrono> #define __cpp_lib_chrono_udls 201304L // also in <chrono> #define __cpp_lib_clamp 201603L // also in <algorithm> #define __cpp_lib_complex_udls 201309L // also in <complex> #define __cpp_lib_concepts 202002L // also in <concepts> #define __cpp_lib_constexpr_algorithms 201806L // also in <algorithm> #define __cpp_lib_constexpr_complex 201711L // also in <complex> #define __cpp_lib_constexpr_dynamic_alloc 201907L // also in <memory> #define __cpp_lib_constexpr_functional 201907L // also in <functional> #define __cpp_lib_constexpr_iterator 201811L // also in <iterator> #define __cpp_lib_constexpr_memory 201811L // also in <memory> #define __cpp_lib_constexpr_numeric 201911L // also in <numeric> #define __cpp_lib_constexpr_string 201907L // also in <string> #define __cpp_lib_constexpr_string_view 201811L // also in <string-view> #define __cpp_lib_constexpr_tuple 201811L // also in <tuple> #define __cpp_lib_constexpr_typeinfo 202106L // also in <typeinfo> #define __cpp_lib_constexpr_utility 201811L // also in <utility> #define __cpp_lib_constexpr_vector 201907L // also in <vector> #define __cpp_lib_coroutine 201902L // also in <coroutine> #define __cpp_lib_destroying_delete 201806L // also in <new> #define __cpp_lib_enable_shared_from_this 201603L // also in <memory> #define __cpp_lib_endian 201907L // also in <bit> #define __cpp_lib_erase_if 202002L // also in <string>, <deque>, <forward-list>, <list>, <vector>, <map>, <set>, <unordered-map>, // <unordered-set> #define __cpp_lib_exchange_function 201304L // also in <utility> #define __cpp_lib_execution 201902L // also in <execution> #define __cpp_lib_filesystem 201703L // also in <filesystem> #define __cpp_lib_format 202110L // also in <format> #define __cpp_lib_gcd_lcm 201606L // also in <numeric> #define __cpp_lib_generic_associative_lookup 201304L // also in <map>, <set> #define __cpp_lib_generic_unordered_lookup 201811L // also in <unordered-map>, <unordered-set> #define __cpp_lib_hardware_interference_size 201703L // also in <new> #define __cpp_lib_has_unique_object_representations 201606L // also in <type-traits> #define __cpp_lib_hypot 201603L // also in <cmath> #define __cpp_lib_incomplete_container_elements 201505L // also in <forward-list>, <list>, <vector> #define __cpp_lib_int_pow2 202002L // also in <bit> #define __cpp_lib_integer_comparison_functions 202002L // also in <utility> #define __cpp_lib_integer_sequence 201304L // also in <utility> #define __cpp_lib_integral_constant_callable 201304L // also in <type-traits> #define __cpp_lib_interpolate 201902L // also in <cmath>, <numeric> #define __cpp_lib_invoke 201411L // also in <functional> #define __cpp_lib_invoke_r 202106L // also in <functional> #define __cpp_lib_is_aggregate 201703L // also in <type-traits> #define __cpp_lib_is_constant_evaluated 201811L // also in <type-traits> #define __cpp_lib_is_final 201402L // also in <type-traits> #define __cpp_lib_is_invocable 201703L // also in <type-traits> #define __cpp_lib_is_layout_compatible 201907L // also in <type-traits> #define __cpp_lib_is_nothrow_convertible 201806L // also in <type-traits> #define __cpp_lib_is_null_pointer 201309L // also in <type-traits> #define __cpp_lib_is_pointer_interconvertible 201907L // also in <type-traits> #define __cpp_lib_is_scoped_enum 202011L // also in <type_traits> #define __cpp_lib_is_swappable 201603L // also in <type-traits> #define __cpp_lib_jthread 201911L // also in <stop-token>, <thread> #define __cpp_lib_latch 201907L // also in <latch> #define __cpp_lib_launder 201606L // also in <new> #define __cpp_lib_list_remove_return_type 201806L // also in <forward-list>, <list> #define __cpp_lib_logical_traits 201510L // also in <type-traits> #define __cpp_lib_make_from_tuple 201606L // also in <tuple> #define __cpp_lib_make_reverse_iterator 201402L // also in <iterator> #define __cpp_lib_make_unique 201304L // also in <memory> #define __cpp_lib_map_try_emplace 201411L // also in <map> #define __cpp_lib_math_constants 201907L // also in <numbers> #define __cpp_lib_math_special_functions 201603L // also in <cmath> #define __cpp_lib_memory_resource 201603L // also in <memory-resource> #define __cpp_lib_monadic_optional 202110L // also in <optional> #define __cpp_lib_move_only_function 202110L // also in <functional> #define __cpp_lib_node_extract 201606L // also in <map>, <set>, <unordered-map>, <unordered-set> #define __cpp_lib_nonmember_container_access 201411L // also in <array>, <deque>, <forward-list>, <iterator>, <list>, <map>, <regex>, <set>, <string>, // <unordered-map>, <unordered-set>, <vector> #define __cpp_lib_not_fn 201603L // also in <functional> #define __cpp_lib_null_iterators 201304L // also in <iterator> #define __cpp_lib_optional 202106L // also in <optional> #define __cpp_lib_out_ptr 202106L // also in <memory> #define __cpp_lib_parallel_algorithm 201603L // also in <algorithm>, <numeric> #define __cpp_lib_polymorphic_allocator 201902L // also in <memory> #define __cpp_lib_quoted_string_io 201304L // also in <iomanip> #define __cpp_lib_ranges 202110L // also in <algorithm>, <functional>, <iterator>, <memory>, <ranges> #define __cpp_lib_ranges_starts_ends_with 202106L // also in <algorithm> #define __cpp_lib_ranges_zip 202110L // also in <ranges>, <tuple>, <utility> #define __cpp_lib_raw_memory_algorithms 201606L // also in <memory> #define __cpp_lib_remove_cvref 201711L // also in <type-traits> #define __cpp_lib_result_of_sfinae 201210L // also in <functional>, <type-traits> #define __cpp_lib_robust_nonmodifying_seq_ops 201304L // also in <algorithm> #define __cpp_lib_sample 201603L // also in <algorithm> #define __cpp_lib_scoped_lock 201703L // also in <mutex> #define __cpp_lib_semaphore 201907L // also in <semaphore> #define __cpp_lib_shared_mutex 201505L // also in <shared-mutex> #define __cpp_lib_shared_ptr_arrays 201707L // also in <memory> #define __cpp_lib_shared_ptr_weak_type 201606L // also in <memory> #define __cpp_lib_shared_timed_mutex 201402L // also in <shared-mutex> #define __cpp_lib_shift 201806L // also in <algorithm> #define __cpp_lib_smart_ptr_for_overwrite 202002L // also in <memory> #define __cpp_lib_source_location 201907L // also in <source-location> #define __cpp_lib_span 202002L // also in <span> #define __cpp_lib_spanstream 202106L // also in <spanstream> #define __cpp_lib_ssize 201902L // also in <iterator> #define __cpp_lib_stacktrace 202011L // also in <stacktrace> #define __cpp_lib_starts_ends_with 201711L // also in <string>, <string-view> #define __cpp_lib_stdatomic_h 202011L // also in <stdatomic.h> #define __cpp_lib_string_contains 202011L // also in <string>, <string_view> #define __cpp_lib_string_resize_and_overwrite 202110L // also in <string> #define __cpp_lib_string_udls 201304L // also in <string> #define __cpp_lib_string_view 201803L // also in <string>, <string-view> #define __cpp_lib_syncbuf 201803L // also in <syncstream> #define __cpp_lib_three_way_comparison 201907L // also in <compare> #define __cpp_lib_to_address 201711L // also in <memory> #define __cpp_lib_to_array 201907L // also in <array> #define __cpp_lib_to_chars 201611L // also in <charconv> #define __cpp_lib_to_underlying 202102L // also in <utility> #define __cpp_lib_transformation_trait_aliases 201304L // also in <type-traits> #define __cpp_lib_transparent_operators 201510L // also in <memory>, <functional> #define __cpp_lib_tuple_element_t 201402L // also in <tuple> #define __cpp_lib_tuples_by_type 201304L // also in <utility>, <tuple> #define __cpp_lib_type_identity 201806L // also in <type-traits> #define __cpp_lib_type_trait_variable_templates 201510L // also in <type-traits> #define __cpp_lib_uncaught_exceptions 201411L // also in <exception> #define __cpp_lib_unordered_map_try_emplace 201411L // also in <unordered-map> #define __cpp_lib_unwrap_ref 201811L // also in <type-traits> #define __cpp_lib_variant 202102L // also in <variant> #define __cpp_lib_void_t 201411L // also in <type-traits>
__cpp_lib_freestanding_operator_newis defined to the integer literal
new-valif all of the library provided replaceable global allocation functions meet the requirements of a hosted implementation, and to the integer literal
0otherwise. ([new.delete]).Recommended practice: Freestanding implementations should only define a macro from
<version>if the implementation provides the corresponding facility in its entirety.