CPS supports a notion of compiler and linker "features", which are used to abstract requirements that consumers of a component modify the default compiler and/or linker behavior in order to deal with functional inconsistencies across tools. While it is ultimately up to the build tool to determine how to map features to tool invocation flags, it is clearly beneficial to attempt to standardize a set of "well known" features. Known features shall be case-insensitive, however compiler specific portions might be case sensitive. (For example, :feature:`warn:error` and :feature:`Warn:Error` are the same feature, but :feature:`warn:foo` and :feature:`warn:Foo` should be treated as different, unless the tool has sufficient knowledge of the compiler to know otherwise.)
The component's public interface
makes use of features included in ISO/IEC 9899:1999.
Code using the component should be compiled
in a mode which supports ISO/IEC 9899:1999 (e.g. --std=c99 or later).
The component's public interface
makes use of features included in ISO/IEC 9899:2011.
Code using the component should be compiled
in a mode which supports ISO/IEC 9899:2011 (e.g. --std=c11 or later).
The component's public interface
makes use of features included in ISO/IEC 14882:2003.
Code using the component should be compiled
in a mode which supports ISO/IEC 14882:2003 (e.g. --std=c++03 or later).
The component's public interface
makes use of features included in ISO/IEC 14882:2011.
Code using the component should be compiled
in a mode which supports ISO/IEC 14882:2011 (e.g. --std=c++11 or later).
The component's public interface
makes use of features included in ISO/IEC 14882:2014.
Code using the component should be compiled
in a mode which supports ISO/IEC 14882:2014 (e.g. --std=c++14 or later).
The component's public interface
makes use of features included in ISO/IEC 14882:2017.
Code using the component should be compiled
in a mode which supports ISO/IEC 14882:2017 (e.g. --std=c++17 or later).
The component's public interface makes use
of features which are GNU extensions.
Code using the component should be compiled
in a mode which supports GNU extensions
(e.g. --std=gnu or --std=gnu++).
Code using the component should either
enable (:feature:`warn`) or disable (:feature:`nowarn`)
the specified warning.
The warnings are compiler specific,
e.g. warn:reorder (GCC, Clang)
or warn:4513 (MSVC).
Tools are expected to recognize if a warning is applicable to the compiler and source language being used (e.g. by attempting to build a test program with the warning in question), and to ignore the feature otherwise.
Code using the component should either treat all warnings as errors (:feature:`warn:error`), or should not treat warnings as errors (:feature:`nowarn:error`).
Code using the component should either enable (:feature:`error`) the specified warning, additionally promoting it to an error, or should not treat the specified warning as an error (:feature:`noerror`). As with :feature.opt:`no`:feature:`warn:`:feature.var:`...`, the warnings are compiler specific. Note that :feature:`noerror` traditionally does not indicate whether the specified warning should be issued or not, only that if it is issued, it should not be promoted to an error.
Code using the component should be built
with run-time threading support.
On Windows, this would typically be used
to select the multi-threaded CRT library
rather than the single-threaded CRT.
On POSIX platforms, it typically indicates
that the application should be built with -pthread.