René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Constexpr does not enforce compile-time evaluation","articleBody":"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.\r\n\r\nWhat 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.\r\n\r\nCompilers are not forced to evaluate constexpr operations at compile-time, and indeed, [for a sufficiently complex expression, they won't](https://godbolt.org/z/zG4b1jfe6). 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.\r\n\r\nAll 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.","author":{"url":"https://github.com/HadrienG2","@type":"Person","name":"HadrienG2"},"datePublished":"2024-03-23T18:54:08.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/276/algorithmica/issues/276"}