Constexpr constructor is not evaluated at compile time

Question

I want to introduce strong types with error checking at compile time. For my chrono type, I noticed literals are silently narrowed when the underlying type changes from int64_t to int32_t, leading to overflows. So I introduced an explicit check.

However this check is not checked at compile time even for constant parameters, like delay_t {10s}, which cannot be represented.

#include <chrono> #include <cstdint> #include <stdexcept> struct delay_t { std::chrono::duration<int32_t, std::nano> value {}; constexpr explicit delay_t(std::chrono::duration<int64_t, std::nano> delay) : value {delay} { if (value != delay) { throw std::runtime_error("delay cannot be represented."); } }; }; auto foo(delay_t delay) -> void {} auto main() -> int { using namespace std::chrono_literals; foo(delay_t {10s}); // here I want a compile time error, // but I get a runtime error. return 0; }

godbolt

This unfortunately compiles and leads to a runtime error. I verified that the literal operator"" s is a constexpr and it works using consteval in the delay_t constructor. I also want to use the type with runtime values, so that's not an option.

How can I tell the compiler above to evaluate constant literals like time_t {10s} at compile time? I am using C++20.

Maybe just don't use an int32_t for nanosecond precision? — Nicol Bolas
– Nicol Bolas, Commented Jan 5, 2023 at 15:27

Jarod42 · Accepted Answer · 2023-01-05 15:27:36Z

5

constexpr is evaluated at compile time only in constant expression, not depending of argument.

You might split your expression as

constexpr delay_t delay{10s}; // Compile time evaluated, so error at compile time foo(delay);

answered Jan 5, 2023 at 15:27

Jarod42

227k15 gold badges214 silver badges349 bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

Chris Over a year ago

Thank you Jarod, this is indeed a very simple and direct solution. I posted an alternative, that doesn't require cooperation by the user of the class. I am not sure yet, if I will go with that, as it requires quite some boilerplate.

Eric M Schmidt · Accepted Answer · 2023-01-05 22:14:13Z

Pass it through a consteval function.

template<typename T> consteval T force_constexpr(const T& value) noexcept { return value; }

You can use it like this:

foo(force_constexpr(delay_t {0s})); // No compile-time error foo(force_constexpr(delay_t {10s})); // Compile-time error

Thank you Eric, I realized through your example that to have the compile-time check we need a consteval function. I combined your idea, while providing an alternative constructor. I am not sure with what I will go, but your solution is definitely an interesting one.

Chris · Accepted Answer · 2023-01-06 10:57:33Z

To force checks at compile time the construction from the chrono type needs to be consteval. There is no way around it.

consteval explicit delay_t(duration<int64_t, std::nano> delay) : delay_t {wrapped_{delay}} {};

To allow also runtime construction we needs an alternative way to construct delay_t. We can for example use a static method that is constexpr.

constexpr static auto runtime(duration<int64_t, std::nano> delay) -> delay_t { return delay_t {wrapped_ {delay}}; }

As this method needs to construct delay_t in some different way, we need a second non-consteval constructor. But as we already have one for chrono, we need to introduce a private wrapper type:

private: struct wrapped_ { duration<int64_t, std::nano> value; }; constexpr delay_t(wrapped_ delay) : value {delay.value} { if (value != delay.value) { throw std::runtime_error("delay cannot be represented."); } };

Using delay_t now enforces compile-time checks by default:

foo(delay_t {1s}); foo(delay_t {10s}); // gives compile time error foo(delay_t::runtime(10s)); // gives a runtime error

Full example on godbolt

Collectives™ on Stack Overflow

Constexpr constructor is not evaluated at compile time

3 Answers 3

1 Comment

1 Comment

Comments

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

1 Comment

1 Comment

Comments

Related