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

111–120 of 120 posts

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

#111

Post by Too »

mwkaufma wrote: post #106
mehrdadn wrote: post #96

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

Add std::array size initialization to that list, as demonstrated in the article.

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

#112

Post by geezerjay »

uncle_bob wrote: post #93
geezerjay wrote: post #63

Earlier quoted context omitted.

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

> Is there a C++ compiler that doesn't include 'make' and/or a 'make' replacement?

Yes, all of them.

Because 'make' and/or 'make' replacements have absolutely zero to do with a compiler. It is a build automation tool that essentially determines which target needs to be built based on which preceding targets have been altered. This has zero to do with what a compiler does.

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

#113

Post by Doxin »

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 ?

D doesn't run code at compile time as an optimisation. It only runs code at compile time in certain constructs like variable declarations or static if statements. If you need your code to run at runtime simply stick it in your code where it needs to run.

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

#114

Post by Doxin »

danellis wrote: post #78
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.

Running code at compile time in D is not an automatic optimization. Only code in certain constructs are ran at compile time, for example function calls in variable declarations or static if statements. Generally it's not something you even need to think about. This runs foo() at compile time:

  int bar=foo();
This runs foo() at runtime:

  int bar;
  void main(){
    bar=foo();
  }

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

#115

Post by JdeBP »

minipci1321 wrote: post #74
JdeBP wrote: post #23

Earlier quoted context omitted.

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, o…

You are making the error of thinking that one can only use one language, or that using the right language for a job is a bad thing; and you are making the error of thinking that build platforms did or do lack the capacity for generating source like this. These are platforms that have the capacity to run a C++ compiler; they have more than enough capacity to run tools like (say) od and sed.

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

#116

Post by nurettin »

geezerjay wrote: post #61
ryandrake wrote: post #44

Earlier quoted context omitted.

If you guys are going three days without testing a release build (let alone three months), then you probably have bigger issues to work through than what constexpr is doing...

The hypothetical odds of having bigger issues does not justify creating additional issues for no reason at all.

which is why they should build release more often.

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

#117

Post by twic »

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…

Beautifully put. This is what's missing from D's approach.

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

#118

Post by tambre »

hzhou321 wrote: post #109
tambre wrote: post #40

Earlier quoted context omitted.

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

If you call searching and text replacement evaluation, then sure.

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

#119

Post by hzhou321 »

tambre wrote: post #118
hzhou321 wrote: post #109

Earlier quoted context omitted.

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.

If you call searching and text replacement evaluation, then sure.

It can be more than that.

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

#120

Post by Joky »

mehrdadn wrote: post #104
Joky wrote: post #103

Earlier quoted context omitted.

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?

No sure I get the question: static_assert can only invoke constexpr functions, and constexpr functions can only call themselves other constexpr functions. Since IO functions are not constexpr, you can't call them there.
Post reply on HN