constexpr error at compile-time, but no overhead at run-time

Question

There is a well-known trick to cause a compile-time error in the evaluation of a constexpr function by doing something like this:

constexpr int f(int x) {
    return (x != 0) ? x : throw std::logic_error("Oh no!");
}

And if the function is used in a constexpr context you will get a compile-time error if x == 0. If the argument to f is not constexpr, however, then it will throw an exception at run time if x == 0, which may not always be desired for performance reasons.

Similar to the theory of assert being guarded by NDEBUG, is there a way to cause a compile-time error with a constexpr function, but not do anything at run time?

Finally, do relaxed constexpr rules in C++1y (C++14) change anything?

Answer 1

Is there a way to cause a compile-time error with a constexpr function, but not do anything at run time?

You can use the exact same trick, but instead of using a throw-expression, use an expression that is not a constant expression but does what you want at runtime. For instance:

int runtime_fallback(int x) { return x; } // note, not constexpr
constexpr int f(int x) {
  return (x != 0) ? x : runtime_fallback(0);
}

constexpr int k1 = f(1); // ok
constexpr int k2 = f(0); // error, can't call 'runtime_fallback' in constant expression
int k3 = f(0);           // ok

Do relaxed constexpr rules in C++1y (C++14) change anything?

Not in this area, no. There are some forms of expression that are valid in constant expressions in C++14 but not in C++11, but neither throw-expressions nor calls to non-constexpr functions are on that list.

Answer 2

If the argument to f is not constexpr, however, then it will throw an exception at run time if x == 0, which may not always be desired for performance reasons.

A function argument is never considered to be a constant expression. The distinction would require compile-time and runtime objects to have different types.

Even though the compiler is using pure functional semantics when it evaluates the function at compile time, it's still the same function with the same meaning. If you want another function of similar but different meaning, you will have to either define another entire function, or make a template.

You could use a signature like this:

template< typename int_type >
constexpr int f(int_type x);

with calls like this:

f( std::integral_constant< int, 0 >() ) // Error.
f( std::integral_constant< int, 3 >() ) // OK.
f( 0 ) // Not checked.

Metaprogramming can tell that integral_constant means a compile-time value. But I don't think it's really appropriate. If one sense of the function works with zero and the other doesn't, then you have two different functions.

A wrapper idiom could prevent duplication among the different functions:

constexpr int f_impl(int x) { // Actual guts of the function.
    return x;
}

int f(int x) { // Non-constexpr wrapper prevents accidental compile-time use.
    assert ( x != 0 && "Zero not allowed!" );
    return f_impl( x );
}

template< int x > // This overload handles explicitly compile-time values.
constexpr int f( std::integral_constant< int, x > ) {
    static_assert ( x != 0, "Zero not allowed!" );
    return f_impl( x );
}

Answer 3

This should work:

#ifdef NDEBUG
    // Suppresses unused variable warnings in release builds.
    #define ASSERT(X) (void(sizeof (X)))
#else
    #define ASSERT(X) ((X) ? void() : std::abort())
#endif

constexpr int f(int const x)
{
    return ASSERT(x != 0), x;
}

You can see the output here. If you add constexpr to the start of line 17 then you'll get a compile-time error instead.

Answer 4

Instead of using a constexpr function, you should use static_assert. This lets you run an assertion at compile-time that has zero runtime cost.

Answer 5

This isn't the most beautiful, but seems to work for my (slightly different) use-case. N.B. that I haven't tested it exhaustively, it may well not be perfect and am sharing in case it's of any help. Will happily take feedback:

// Arguments not guaranteed to be compile-time
constexpr bool singleDigitOnlyIsMultipleOfThree(const unsigned number){
    if ((number / 10) > 0)
        throw std::logic_error("ConstexprError");
    switch(number % 3){
        case 0:  return true;
        case 1:  return false;
        case 2:  return false;
        default: throw std::logic_error("Should be unreachable");
    }
}

// Both arguments and return value guaranteed to be compile-time
template<unsigned number>
constexpr bool singleDigitOnlyIsMultipleOfThree(){
    // Because number is constexpr, we guarantee we go through the above implementatio nas constexpr.
    return singleDigitOnlyIsMultipleOfThree(number);
}


int main(){

    constexpr bool   run1 = singleDigitOnlyIsMultipleOfThree(6);     // true
    constexpr bool   run2 = singleDigitOnlyIsMultipleOfThree(7);     // false
    const     bool   run3 = singleDigitOnlyIsMultipleOfThree(100);   // throws

    constexpr bool const1 = singleDigitOnlyIsMultipleOfThree<6>();   // true
    constexpr bool const2 = singleDigitOnlyIsMultipleOfThree<7>();   // false
    constexpr bool const3 = singleDigitOnlyIsMultipleOfThree<100>(); // does not compile

    cout << run1 << " " << run2 << " " << const1 << " " << const2 << endl;
    
}

This funciton should return a (potentially compile-time) value indicating if the argument is divisible by three, but not allow any value >= 10. When called using template arguments, we have a guaranteed constant expression. When using function brackets as a constant expression, we have a compile-time constant. When using function brackets as a runtime expression, then we will have an exception in lieu of a compiler error.

There is the advantage that we can implement the logic using a constexpr function, thus avoiding the need to do it the old-fashioned way using all template specialisation. So our code is faster to write, more succint, and more expressive. However, we can still call it at compile-time and enforce the constant nature of the output and generate a compile-time error. If we want to gamble with runtime values, then it should have behaiour to match. Major disadvantage is having two separate ways to call the function. If we really want to ensure it's a constant expression, then we need to use the angle-bracket syntax, or force assigning to a constexpr.

Answer 6

This seems to do the trick. It is not very pretty, but the idea is to distinguish value that is available at compile time from one that isn't using SFINAE on constexprs. I can compile this with clang 3.3 and have the compilation fail when I try to use f(0) in a constexpr context, but not throw when I use it at runtime. You can probably create a one-parameter maybethrow overload that makes the (not_)preferred trick internal to its implementation.

struct not_preferred {};
struct preferred { operator not_preferred() { return not_preferred(); } };

template< typename T, T X >
T compiletime() { return X; }

template< typename T >
constexpr auto maybethrow( preferred, T x ) -> decltype( compiletime< T, x >() )
{
    return 0 ? x : throw 1;
}

template< typename T >
constexpr auto maybethrow( not_preferred, T x ) -> T
{
    return x;
}

constexpr int f(int x)
{
    return x ? x + 1 : maybethrow( preferred(), x + 1 );
}