Hacker News new | ask | show | jobs
by jcelerier 1121 days ago
> constexpr isn't a guarantee of it being evaluated at compile time

constexpr is a guarantee that you can use the thing in a constexpr context, and this is where the "evaluated at compile-time" guarantee can come from:

    template<typename T>
    auto func() {
      // here some compilers can still choose to evaluate x at run-time - and very likely all of them if no optimizations are enabled
      constexpr int x = f(); 

      // but here it becomes mandatory for this use of x to be evaluated at compile-time, since the number is literally going to be part of the compiled binary as part of the function name mangling
      return std::integral_constant<int, x>{};
    }
2 comments

Constexpr does not guarantee that a constexpr function can be called at compile time, unfortunately. Only that it can be called at runtime for a subset of all possible parameters.

Except of course the subset of parameters for which it is constexpr callable can't be checked at function definition time (if it exists at all), only at function invocation time.

Which makes the constexpr annotation useless and it is in only because the authors couldn't otherwise get the paper through some committee objections.

Is such a mangling mandated by the standard?
Mangling is mentioned in the standard.

In this case though the underlying reason is that its part of the type (system) not because of the mangle specifically.

> Mangling is mentioned in the standard.

Forgive me, but can you be clearer than "mentioned"? Is the mangling required to contain template parameters for return types?

> In this case though the underlying reason is that its part of the type (system) not because of the mangle specifically.

I'm not sure. The compiler knows it will always be the same type, so under many uses of this function I could easily imagine a compiler that doesn't actually fill in .value until runtime.

> Forgive me, but can you be clearer than "mentioned"? Is the mangling required to contain template parameters for return types?

The mangling will contain template parameters, as you can have:

foo.hpp

    template<typename T>
    T f();
foo.cpp

    template<>
    int f<int>() { return 123; }
    template<>
    float f<float>() { return 123; }
bar.cpp

    std::cout << f<int>();
and the right function has to be found. demo: https://gcc.godbolt.org/z/rMjYoEzaK
Sorry, I meant parameters that only are being returned, and not passed in.

So in the example several layers above, T uniquely identifies the function. I don't see any need to involve std::integral_constant<int, x> in the mangling.

Mangling isn't technically required as per se but it's by far the most common approach (basically a local minimum in terms of cost)

I think this subset of C++ templates is probably undecidable still.