You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This book unfortunately perpetuates the widely held belief that putting a constexpr keyword on code will, on its own, force code to be evaluated at compile time. This is inaccurate. You need C++20's consteval for that.
What constexpr actually does is to constrain code into a subset of the language that can be evaluated at compile time. This, in turn, lets you use constexpr functions and expressions in a context where the output expression must be evaluated at compile time for the program to be correct according to the rules of the language. Think about, for example, computing template non-type parameters.
Compilers are not forced to evaluate constexpr operations at compile-time, and indeed, for a sufficiently complex expression, they won't. Conversely, compilers were able to evaluate expressions at compile time a long time before constexpr was a thing, and will commonly perform the associated const-propagation optimization on code where constexpr is not present.
All in all, the only way constexpr may benefit program optimization is that it forces you to constrain yourself into a subset of the language which is known to be amenable to const-propagation on all modern compilers, and lets you get a compiler error otherwise. This is useful, but not as useful as the current text asserts, so please consider amending it and pointing to consteval instead for the kind of optimizations that you are discussing in the book.
The text was updated successfully, but these errors were encountered:
This book unfortunately perpetuates the widely held belief that putting a constexpr keyword on code will, on its own, force code to be evaluated at compile time. This is inaccurate. You need C++20's consteval for that.
What constexpr actually does is to constrain code into a subset of the language that can be evaluated at compile time. This, in turn, lets you use constexpr functions and expressions in a context where the output expression must be evaluated at compile time for the program to be correct according to the rules of the language. Think about, for example, computing template non-type parameters.
Compilers are not forced to evaluate constexpr operations at compile-time, and indeed, for a sufficiently complex expression, they won't. Conversely, compilers were able to evaluate expressions at compile time a long time before constexpr was a thing, and will commonly perform the associated const-propagation optimization on code where constexpr is not present.
All in all, the only way constexpr may benefit program optimization is that it forces you to constrain yourself into a subset of the language which is known to be amenable to const-propagation on all modern compilers, and lets you get a compiler error otherwise. This is useful, but not as useful as the current text asserts, so please consider amending it and pointing to consteval instead for the kind of optimizations that you are discussing in the book.
The text was updated successfully, but these errors were encountered: