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

101–110 of 120 posts

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

#101

Post by mehrdadn »

StephanTLavavej wrote: post #100
mehrdadn wrote: post #97

Earlier quoted context omitted.

(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 expression…

I see, so you're saying it's a verifiable promise by the function writer that it can be evaluated at compile-time?

Meaning its entire purpose is to just be an easier version of a compile-time unit-test like static_assert(f(1) == 2)?

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

#102

Post by soulbadguy »

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…

How does D deal with cases where the computation might be plaform dependent (like floating point arth. or bit kung-fu+ endianess) ? An more generally, what happens when a computation "can" be done at compile time , but "needs" (for correctness or ressource ) done at runtime ?

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

#103

Post by Joky »

mehrdadn wrote: post #82
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…

> It is expected that some corners of the language will never be available at compile time, for example I/O. So you're saying functions that have side-effects like I/O can actually perform those operations at compile-time if marked with constexpr?

No: the purpose of constexpr is that the compiler would issue an error if a constexpr function contains such side-effects.

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

#104

Post by mehrdadn »

Joky wrote: post #103
mehrdadn wrote: post #82

Earlier quoted context omitted.

> It is expected that some corners of the language will never be available at compile time, for example I/O. So you're saying functions that have side-effects like I/O can actually perform those operations at compile-time if marked with constexpr?

No: the purpose of constexpr is that the compiler would issue an error if a constexpr function contains such side-effects.

No? Wouldn't it do that with a static_assert invoking the function too?

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

#105

Post by WalterBright »

soulbadguy wrote: post #102
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…

How does D deal with cases where the computation might be plaform dependent (like floating point arth. or bit kung-fu+ endianess) ? An more generally, what happens when a computation "can" be done at compile time , but "needs" (for correctness or ressource ) done at runtime ?

The same way constant folding is done in any compiler. You try to emulate the math on the target.

D is quite specific what computations occur at compile time and what at runtime. It's very much up to the user in how he sets it up.

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

#106

Post by mwkaufma »

mehrdadn wrote: post #96
mwkaufma wrote: post #94

Earlier quoted context omitted.

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…

>> But how does it lead to better feedback?

Because you can use static_asset (only accepts constexprs) and in C++17 static-if (a first class cousin to #if)

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

#107

Post by barsonme »

WalterBright wrote: post #87
jstimpfle wrote: post #81

Earlier quoted context omitted.

I think this might waste resources for some transient results. Sometimes that computation time required for evaluation is negligible, and the result might require more memory than "the function call".

It's been in D for a decade, and has been extremely successful, to the extent of becoming a critical feature. An early example was someone wrote a ray tracer in D that ran and generated output completely at compile time. A more useful example is D's regex package can build the engine at compile time, thereby emitting a custom engine for the regex, instead of at runtime.

While I think it's awesome D can do that (and am a bit jealous the languages I use regularly don't have any real sort of constexpr) what does that _really_ provide?

It would seem the startup cost of building a regexp engine would really only matter for, say, command-line programs (i.e., short-lived, run-once programs). For a web application the overhead would be negligible.

Again, don't get me wrong, but it just seems to be more of a "neat!" thing than a "we _need_ this for reasons X, Y, and Z."

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

#108

Post by WalterBright »

barsonme wrote: post #107
WalterBright wrote: post #87

Earlier quoted context omitted.

It's been in D for a decade, and has been extremely successful, to the extent of becoming a critical feature. An early example was someone wrote a ray tracer in D that ran and generated output completely at compile time. A more useful example is D's regex package can build the engine at compile time, thereby emitting a custom engine for the regex, instead of at runtime.

While I think it's awesome D can do that (and am a bit jealous the languages I use regularly don't have any real sort of constexpr) what does that _really_ provide? It would seem the startup cost of building a regexp engine would really only matter for, say, command-line programs (i.e., short-lived, run-once programs). For a web application the overhead would be negligible. Again, don't get me wrong, but it just seem…

Most regex engines build interpreter bytecode at runtime, and then execute the bytecode with an interpreter. Being able to generate the engine at compile time means the runtime engine is running custom compiled code.

So, what it _really_ provides is runtime performance.

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

#109

Post by hzhou321 »

tambre wrote: post #40
hzhou321 wrote: post #37

If you use a general meta layer preprocessor such as MyDef, you may be able to construct macros that comes from evaluations of code in any languages (instead of restricted in eg. C++ with rather complicated compiler mechanics) A constexpr is a constant that is evaluated from a code at compile time, which is essentially just macros. Right? A general preprocessor that just do language agnostic code manipulations are no…

> A constexpr is a constant that is evaluated from a code at compile time, [...] It's rather a constant expression, which is quite a bit more than a mere constant. > [...] which is essentially just macros. Right? Macros are basically just text replacement. You can't write a macro and expect most compilers to execute the expressions and code inside the macro at compile-time. Some compilers may still to do that, but it…

With a macro, you get guarantee of compile time evaluation, as well as compile time independent literal syntax double check. And you can do better than hint. You can double check the results explicitly. Since it's compile time evaluation, optimization is out of context.

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

#110

Post by hzhou321 »

krylon wrote: post #52
hzhou321 wrote: post #37

If you use a general meta layer preprocessor such as MyDef, you may be able to construct macros that comes from evaluations of code in any languages (instead of restricted in eg. C++ with rather complicated compiler mechanics) A constexpr is a constant that is evaluated from a code at compile time, which is essentially just macros. Right? A general preprocessor that just do language agnostic code manipulations are no…

> a general meta layer preprocessor such as MyDef I did not even know such a thing existed. Thank you!

I didn't find any, so I rolled my own 10 years ago. Most of its features are suited toward very limited users. E.g. it doesn't really support macro evaluation from arbitrary language, only from Perl currently (but general for any target language). However,to support macro evaluation from arbitrary language seems trivial. It'll be just like gcc pulling different compiler together.
Post reply on HN