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

Re:C++17 constexpr everything, or as much as the compiler can by WalterBright on Thursday December 28, 2017 @04:09PM (#16024902)

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.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by soulbadguy on Thursday December 28, 2017 @08:07PM (#16026649)

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 ?

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by WalterBright on Thursday December 28, 2017 @09:05PM (#16026959)

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.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by Doxin on Friday December 29, 2017 @05:14AM (#16028702)

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.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by minipci1321 on Thursday December 28, 2017 @04:23PM (#16024998)

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

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by WalterBright on Thursday December 28, 2017 @05:08PM (#16025370)

You can annotate D functions as 'pure', which would have that effect, but purity is used for other reasons.

Evaluating functions at compile time has another wrinkle in D - it is path dependent:

    int square(int x) {
        if (x < 100)
            return x * x;
        printf("oops\n");
        return 0;
    }
    const int x = square(3); // works
    const int y = square(100); // fails at compile time

I.e. the path taken through the function has to be pure, not every part of the function.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by jstimpfle on Thursday December 28, 2017 @04:37PM (#16025096)

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

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by WalterBright on Thursday December 28, 2017 @05:11PM (#16025400)

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.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by barsonme on Friday December 29, 2017 @01:15AM (#16027961)

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

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by WalterBright on Friday December 29, 2017 @01:33AM (#16028027)

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.

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by danellis on Thursday December 28, 2017 @04:32PM (#16025061)

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

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by Doxin on Friday December 29, 2017 @05:17AM (#16028709)

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();
  }

[ Parent | on HN ]

Re:C++17 constexpr everything, or as much as the compiler can by Veedrac on Thursday December 28, 2017 @05:01PM (#16025303)

D still has optimization passes.

[ Parent | on HN ]