On: C++17’s useful features for embedded systems

[Dylan16807]

Is such a mangling mandated by the standard?

[mhh__ → Dylan16807]

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.

[Dylan16807 → mhh__]

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

[jcelerier → Dylan16807]

> 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

[Dylan16807 → jcelerier]

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.

[jcelerier → Dylan16807]

long story short: https://stackoverflow.com/questions/30057635/why-is-the-retu...

[mhh__ → Dylan16807]

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.