Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++17 constexpr everything, or as much as the compiler can

solarianprogrammer.com

Post reply on HN
Print view View original

91–100 of 120 posts

Re: C++17 constexpr everything, or as much as the compiler can

#91

Post by mwkaufma »

mikepurvis wrote: post #73
mehrdadn wrote: post #71

Earlier quoted context omitted.

> It ensures that the variable could be evaluated at compile time Why couldn't a variable without constexpr be evaluated at compile-time? Nobody ever explains this.

There's precedent in C++ for keywords that give the compiler hints it doesn't necessarily promise to act on: inline.

Shameless pedant kneejerk: 'inline' has semantics in additional to the optimization-hint. e.g. inlined functions won't trigger multiple-definition link-errors, even if they're left as ordinary functions in the executable.

Re: C++17 constexpr everything, or as much as the compiler can

#92

Post by mwkaufma »

lazyjones wrote: post #15

I'm not sure this is really necessary. gcc and Apple's clang optimize the factorial code without "constexpr" and the fibonacci code might be an extreme case avoided by reasonable defaults for the numerous optimization parameters that can be adjusted: max-inline-recursive-depth max-inline-recursive-depth-auto Specifies the maximum recursion depth used for recursive inlining. For functions declared inline, --param max-…

Although ordinary functions can be evaluated at compile time without the constexpr annotation, only constexpr functions will raise an error if it _can't_ be evaluated at compile time (irrespective of if the compile thinks it should be). it's a judgement call for when explicit intent > implicit side-effects.

Re: C++17 constexpr everything, or as much as the compiler can

#93

Post by uncle_bob »

geezerjay wrote: post #63
uncle_bob wrote: post #8

C++ is never just C++. The build system for any C++ program includes both macro language and some form of make and/or make replacement. Explicitly generating tables at compile time and linking is bog standard at this point. Write a table generator program, have output create a table, splice in the order into make and/or make replacement. Sure it's three extra steps, but it's small steps that can be debugged. It also…

> C++ is never just C++. The build system for any C++ program includes both macro language and some form of make and/or make replacement. Your comment makes no sense, and shows some confusion. C++ is a programming language. That's what's being discussed here. You, on the other hand, are talking about build systems and how sofrware projects may be configured by some people. That is besides the point and actually compl…

Is there a C++ compiler that doesn't include 'make' and/or a 'make' replacement? There are linkage rules and even a few keywords just to allow linkage with code not generated by the compiler. It's very much part of the language.

'extern const int *table;'

Having a compile-time program create table would guarantee that it's created at compile time. Having a constexpr does not guarantee it would be done at compile-time, it silently degrades to run-time. If verifying requires an assembly listing, I see it less useful than the currently available tools.

Re: C++17 constexpr everything, or as much as the compiler can

#94

Post by mwkaufma »

mehrdadn wrote: post #70

I have yet to understand what information 'constexpr' conveys to the compiler that makes it necessary or useful.

Like "const", it's so the compiler can produce better feedback for the programmer, not better executables. constexpr will raise an error if a function _can't_ be evaluated at compile-time, just as const functions will raise an error if they do any non-const stuff.

Re: C++17 constexpr everything, or as much as the compiler can

#95

Post by mwkaufma »

dkrikun wrote: post #54

I personally do not understand the buzz around constexpr etc. All the real buziness is happening at runtime anyway and compilers already optimize code quite decently. The extra maintenance burden just doesn't pays off.

It's like 'const' itself -- it's a tool for producing better error messages, not better final executables.

Re: C++17 constexpr everything, or as much as the compiler can

#96

Post by mehrdadn »

mwkaufma wrote: post #94
mehrdadn wrote: post #70

I have yet to understand what information 'constexpr' conveys to the compiler that makes it necessary or useful.

Like "const", it's so the compiler can produce better feedback for the programmer, not better executables. constexpr will raise an error if a function _can't_ be evaluated at compile-time, just as const functions will raise an error if they do any non-const stuff.

> Like "const", it's so the compiler can produce better feedback for the programmer, not better executables. constexpr will raise an error if a function _can't_ be evaluated at compile-time, just as const functions will raise an error if they do any non-const stuff.

But how does it lead to better feedback? constexpr is purely suggesting an optimization that the compiler was already allowed to do anyway, and which it can still refuse to perform even with the keyword.

If the programmer's goal is to ensure compile-time evaluation is guaranteed, constexpr won't cut it, since the compiler can (and compilers currently do) silently fall back to run-time evaluation.

Alternatively, if the programmer's goal is to ensure compile-time evaluation is possible, constexpr still doesn't provide any value, since that's already obvious from the compiler analyzing the body of the function and noticing, say, that fopen() is getting called (and the compiler already has to do this anyway).

The situation is very critically different from const, too. Adding 'const' to a method that was previously non-const, even when it is legal and compiles perfectly fine, can entirely change the semantics of the code, and hence you want that decision to be explicit, not implicit. This isn't the case with constexpr.

Re: C++17 constexpr everything, or as much as the compiler can

#97

Post by mehrdadn »

gpderetta wrote: post #80
mehrdadn wrote: post #71

Earlier quoted context omitted.

> It ensures that the variable could be evaluated at compile time Why couldn't a variable without constexpr be evaluated at compile-time? Nobody ever explains this.

The option was discussed during standardization. It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation details and wouldn't be possible to check it in isolation. It might not be a great reason (some code becomes a keyword soup…

(EDIT to my last comment since I can't actually edit it -- I'm not sure if I misinterpreted your comment earlier or if you updated yours, but this is my updated reply.)

> It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation details and wouldn't be possible to check it in isolation.

Don't compilers already require the implementation of a function to be there in order to evaluate the code at compile-time? And don't they already have to verify that it can indeed be called at compile-time? I don't really get what the constexpr flag helps the compiler. It could just assume everything is constexpr implicitly unless proven otherwise.

Re: C++17 constexpr everything, or as much as the compiler can

#98

Post by contrarian_ »

jotux wrote: post #53
DamonHD wrote: post #43

I am already a big fan of constexpr-ing everything that doesn't run away or make the compiler cry for our embedded application. Yes, we are building a substantial embedded system with (a constrained subset of; no heap, but some templates for example) C++ 11. Heretical, I understand.

In the last ~five years I've converted all my embedded software development to C++11, even projects on small microcontrollers (32kb flash, 8kb RAM). There are features I don't use but it's hard to imagine going back to C at this point.

On the contrary, I've gone back to plain C for most projects and it's been a real relief after using C++11/14 extensively. So much accidental complexity just disappears.

The compile times are much better, too. Can't wait to get a Threadripper CPU which should push the build even closer to feeling instant.

Re: C++17 constexpr everything, or as much as the compiler can

#99

Post by marmaduke »

HelloNurse wrote: post #41
jcelerier wrote: post #25

Earlier quoted context omitted.

or you can just use a C++ repl like Cling ?

What the C++ repl does with constexpr functions would be unrelated to the code generated by the actual C++ compiler.

since Cling is just Clang in a REPL, it seems like it would be good idea

Re: C++17 constexpr everything, or as much as the compiler can

#100

Post by StephanTLavavej »

mehrdadn wrote: post #97
gpderetta wrote: post #80

Earlier quoted context omitted.

The option was discussed during standardization. It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation details and wouldn't be possible to check it in isolation. It might not be a great reason (some code becomes a keyword soup…

(EDIT to my last comment since I can't actually edit it -- I'm not sure if I misinterpreted your comment earlier or if you updated yours, but this is my updated reply.) > It is expected that some corners of the language will never be available at compile time, for example I/O. So you need a keyword to declare a function to be callable a compile time, otherwise its constexpressness would depend on its implementation d…

constexpr isn't just a claim about today - it's a promise for the future. That is, the compiler can certainly notice that a function can be evaluated at compile time, and indeed optimizers will often perform enough inlining and constant propagation to boil down function calls to constant values in the binary. The constexpr keyword serves two purposes: it claims that the implementation is usable in constant expressions today (therefore allowing compilers to diagnose (i.e. emit compiler errors for) things that can't be done at compiletime, like I/O), and it promises that the implementation won't change in the future to be hostile to compile-time evaluation. This promise is important - otherwise, users could take a dependency on a function's current behavior (e.g. by using its result as an array bound, or as a template argument), and then they would be broken by implementation changes in the future that prohibited compile-time evaluation.
Post reply on HN