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

71–80 of 120 posts

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

#71

Post by mehrdadn »

mnarayan01 wrote: post #35
andrepd wrote: post #19

>In conclusion, at the time of this writing, you need to inspect the generated code of your compiler, if you want to be sure that something is really calculated at compile time. I don't get this. Why? Doesn't making a variable constexpr ensure it is a compile time value, or it will fail to compile?

> Doesn't making a variable constexpr ensure it is a compile time value It ensures that the variable could be evaluated at compile time, where "could be evaluated at compile time" means "conforms to the rules set forth in the C++ standard". Whether or not it is computed at compile time is dependent on the compiler.

> 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.

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

#72

Post by minipci1321 »

mehrdadn wrote: post #70

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

Certain things, when used in a routine, make computation impossible at compile time. If the routine is marked with 'constexpr', the compiler will verify that.

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

#73

Post by mikepurvis »

mehrdadn wrote: post #71
mnarayan01 wrote: post #35

Earlier quoted context omitted.

> Doesn't making a variable constexpr ensure it is a compile time value It ensures that the variable could be evaluated at compile time, where "could be evaluated at compile time" means "conforms to the rules set forth in the C++ standard". Whether or not it is computed at compile time is dependent on the compiler.

> 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.

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

#74

Post by minipci1321 »

JdeBP wrote: post #23
Elv13 wrote: post #17

Earlier quoted context omitted.

And have all embedded engineers raging because you just made cross compilation an order of magnitude harder.

The secret there, of course, is not to write the table generation program in C++. (-: In such circumstances, I find myself writing the table generator in shell script, REXX, or some such convenient language on the host system.

Sounds like opening a can of worms ... some developers will definitely opt for using a language which has "convenient" properties -- since the generator code is not running on the target platform, it has different constraints. And then one day, another dev team will face the task of porting rexx/perl/python/ocaml/you-name-it on a platform which has no capacities for that, or has no required depenedencies available, or neither.

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

#75

Post by WalterBright »

D doesn't need constexpr. It's much simpler - any function whose value is needed at compile time is evaluated at compile time. For example:

    int square(int x) { return x * x; }
    const y = square(3); // evaluated at compile time
    int bar() {
        int[square(2)] array; // evaluated at compile time
        return square(3); // evaluated at run time
    }
If a value is needed at compile time, and the function cannot be evaluated at compiler time (i.e. it relies on things like global variables not known at compile time) then a compilation error is issued.

There isn't any ambiguity about whether it is evaluated at runtime or compile time - there is no "fall back" to run time if it can't be done at compile time.

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

#76

Post by minipci1321 »

WalterBright wrote: post #75

D doesn't need constexpr. It's much simpler - any function whose value is needed at compile time is evaluated at compile time. For example: int square(int x) { return x * x; } const y = square(3); // evaluated at compile time int bar() { int[square(2)] array; // evaluated at compile time return square(3); // evaluated at run time } If a value is needed at compile time, and the function cannot be evaluated at compiler…

Maybe 'constexpr' has been added rather to express the intent (for example, for library development)?

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

#77

Post by mehrdadn »

minipci1321 wrote: post #72
mehrdadn wrote: post #70

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

Certain things, when used in a routine, make computation impossible at compile time. If the routine is marked with 'constexpr', the compiler will verify that.

Couldn't it already do the exact same thing without constexpr? (And shouldn't it have already done that when optimizing? In fact for simpler expressions compilers already do this, right?) How does specifying constexpr help?

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

#78

Post by danellis »

WalterBright wrote: post #75

D doesn't need constexpr. It's much simpler - any function whose value is needed at compile time is evaluated at compile time. For example: int square(int x) { return x * x; } const y = square(3); // evaluated at compile time int bar() { int[square(2)] array; // evaluated at compile time return square(3); // evaluated at run time } If a value is needed at compile time, and the function cannot be evaluated at compiler…

What about values that aren't needed at compile time, but can be so optimized.

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

#79

Post by mehrdadn »

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.

Happy to be corrected (EDIT: indeed, I stand corrected! see replies below), but I don't think the C++ spec says anything about 'inline' encouraging the compiler to inline the compiled code?

'auto' would've been an example, but that also got removed, because they realized it was useless. I don't get how constexpr is any different.

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

#80

Post by gpderetta »

mehrdadn wrote: post #71
mnarayan01 wrote: post #35

Earlier quoted context omitted.

> Doesn't making a variable constexpr ensure it is a compile time value It ensures that the variable could be evaluated at compile time, where "could be evaluated at compile time" means "conforms to the rules set forth in the C++ standard". Whether or not it is computed at compile time is dependent on the compiler.

> 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 with all the pointless boilerplate, we really need a DWIM[1] keyword).

[1] Declare With Implicit Meaning of course.

Post reply on HN