|
BDE 4.14.0 Production release
|
Macros | |
| #define | BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED |
| #define | BSLS_CONSTEVAL_CONSTEXPR |
| #define | BSLS_CONSTEVAL_CONSTEXPR_MEMBER const |
Provide macros related to compile-time evaluation.
true during constant evaluationconstexpr if IS_ACTIVE definedconstexpr if IS_ACTIVE, else constThis component provides preprocessor macros that, when possible, will identify if a function is being evaluated at compile time. This enables branching to avoid the use of constructs that would not be valid to evaluate at compile time. When available, the std::is_constant_evaluated() function will be used. On some platforms where that is unavailable a compiler intrinsic will be used instead. Finally, when no option for this functionality is available the BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED macro will expand to nothing and BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED_IS_ACTIVE will not be defined. To ease writing declarations of functions where there is conditionally available compile-time behavior, BSLS_CONSTEVAL_CONSTEXPR is defined to be equivalent to constexpr if BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED_IS_ACTIVE is defined.
This section documents the preprocessor macros defined in this component.
BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED This macro expands to std::is_constant_evaluated when it is available, or to a compiler intrinsic with equivalent functionality if available, else, it expands to nothing.
BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED_IS_ACTIVE This macro is defined to 1 if BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED can be used to identify compile-time evaluation, and is undefined otherwise.
BSLS_CONSTEVAL_CONSTEXPR This macro is defined to be constexpr if BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED_IS_ACTIVE is defined, otherwise it is defined as empty.
BSLS_CONSTEVAL_CONSTEXPR_MEMBER This macro is defined to be constexpr if BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED_IS_ACTIVE is defined; otherwise it is const. This should be applied to variables and member variables that should be initialized by a function that is BSLS_CONSTEVAL_CONSTEXPR.
This section illustrates intended use of this component.
In this simple example, the macros are used to determine when it is permissible to log a message to stdout.
Now we define a test1 function to invoke compute in different contexts. This function can be evaluated both at runtime and at compile time without errors. Below, this function is evaluated in both cases, and the difference in behavior is observed.
When 17 == i or 17 == j, compute will write "Computing value/n" to stdout. So, this message will be written once or twice depending on whether BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED_IS_ACTIVE is defined. The variable j will always be const, and on platforms where the compute function supports being constexpr, i.e. those where it can use BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED to suppress its use of standard output, j will also be constexpr and its value will be computed at compile time.
Consider the situation where there exist two implementations of the same algorithm, one of which satisfies the (stringent and pessimizing) requirements needed to be a C++11 constexpr function, the other of which takes advantage of runtime optimizations (such as hardware acceleration, exceptions, or non-constexpr third-party libraries) that are not available at compile time on any platform:
Assuming these functions were introduced long ago, it is likely they are heavily used wherever valid throughout a codebase. The compiletimeCompute function is likely used to initialize many const and constexpr variables, but also potentially used in many runtime-only expressions, or as part of other constexpr functions that are themselves sometimes used at runtime. The runtimeCompute function, similarly, is likely used in many contexts that could become constexpr or be evaluated at compile time, but is hindering that due to itself not being constexpr.
We can begin to transform compiletimeCompute and runtimeCompute to both have improved performance wherever they might be used by moving their implementations to separate functions:
Then, for compiletimeCompute we can provide a new implementation that will use the better runtime algorithm when possible, while remaining constexpr on all of the platforms where it previously was constexpr (i.e., without changing its declaration):
Now clients using compiletimeCompute at runtime, both within and outside of other constexpr functions, will get the benefits of an improved algorithm without any need for change.
Similarly, the implementation of runtimeCompute can be improved to be opportunistically constexpr by taking advantage of BSLS_CONSTEVAL_CONSTEXPR, potentially allowing some already existing expressions to be compile time evaluated on more modern platforms:
Clients of runtimeCompute can continue to use it at runtime with no changes, occasionally getting the benefits of the compile-time algorithm. When using runtimeCompute to initialize a variable, the compile-time behavior can be forced by annotating the variable with BSLS_CONSTEVAL_CONSTEXPR_MEMBER.
With these changes, clients on older platforms can continue to take advantage of having optimal algorithms available at both compile time and runtime while getting the best available implementation on newer platforms that enable the detection of compile-time evaluation.
| #define BSLS_CONSTEVAL_CONSTEXPR |
| #define BSLS_CONSTEVAL_CONSTEXPR_MEMBER const |
| #define BSLS_CONSTEVAL_IS_CONSTANT_EVALUATED |