constexpr overloading

I agree that this feature is missing - I need it too. Example:

double pow(double x, int n) {
    // calculate x to the power of n
    return ...
}

static inline double pow (double x, constexpr int n) {
    // a faster implementation is possible when n is a compile time constant
    return ...
}

double myfunction (double a, int b) {
    double x, y;
    x = pow(a, b);  // call version 1 unless b becomes a compile time constant by inlining
    y = pow(a, 5),  // call version 2
    return x + y;
}

Now I have to do this with templates:

template <int n>
static inline double pow (double x) {
    // fast implementation of x ^ n, with n a compile time constant
    return ...
}

This is fine, but I miss the overload opportunity. If I make a library function for others to use then it is inconvenient that the user has to use different function calls depending on whether n is a compile time constant or not, and it may be difficult to predict whether the compiler has reduced n to a compile time constant or not.

TL;DR: It is possible in C++20, with std::is_constant_evaluated in the <type_traits> header.

I came across this question with the application that @Öö Tiib mentioned in his answer, in mind: I wanted to use a faster algorithm at runtime, but a slower (and constexpr-friendly) algorithm at compile-time.

Using the example in @Öö Tiib's answer:

#include <iostream>
#include <type_traits>

constexpr int foo(int i) {
    if (std::is_constant_evaluated()) {
        // compile-time branch
        return (i > 1) ? foo(i - 1) * i : 1;
    } else {
        // runtime branch
        return 42;
    }
}

int main(int argc, char* argv[]) {
    int a = foo(1);
    const int b = foo(2);
    constexpr int c = foo(3);
    const int d = foo(argc);

    std::cout << a << std::endl;
    std::cout << b << std::endl;
    std::cout << c << std::endl;
    std::cout << d << std::endl;
}

gives the output

2
2
6
42

Here is a link to the program on godbolt.

Note that foo is indeed a legal constexpr function because, as the standard says, (quote copied from cppreference):

A constexpr function must satisfy the following requirements:

• there exists at least one set of argument values such that an invocation of the function could be an evaluated subexpression of a core constant expression (for constructors, use in a constant initializer is sufficient).

Note, however, that this program:

#include <iostream>
#include <type_traits>

constexpr int foo(int i) {
    if (std::is_constant_evaluated()) {
        // compile-time branch
        return i > 1 ? foo(i - 1) * i : 1;
    } else {
        // runtime branch
        return 42;
    }
}

int main(int argc, char *argv[]) {
    int a = 1;
    const int b = 2;
    constexpr int c = 3;
    const int d = argc;

    std::cout << foo(a) << std::endl;
    std::cout << foo(b) << std::endl;
    std::cout << foo(c) << std::endl;
    std::cout << foo(d) << std::endl;
}

gives the output

42
42
42
42

(Godbolt link)

I'm not entirely sure why this happens, but I suspect that it is because std::cout's operator<< is not marked constexpr, so all the function calls to foo are happening at runtime. Interestingly, however, in Godbolt's assembly output (for x86-64 GCC 11.2), we can see the 42s inlined. So the function is indeed evaluated at compile-time, just not in the way we would expect at first.

Edit: Trick described below is not guaranteed to work anymore!

Detecting constexpr can't be made using overloads (like others already replied) but overloads are just one way to do it.

The typical problem is that we can't use something that can improve run-time performance (for example to call non-constexpr functions or to cache results) in constexpr function. So we may end up with two different algorithms, one less efficient but writable as constexpr, other optimized to run fast but not constexpr. Then we want compiler not to choose the constexpr algorithm for run-time values and vice versa.

That can be achieved by detecting constexpr and selecting based on it "manually" and then shortening the interface down with preprocessor macros.

First lets have two functions. In general the functions should reach same result with different algorithms. I choose two algorithms that never give same answers here just to test and to illustrate the idea:

#include <iostream>     // handy for test I/O
#include <type_traits>  // handy for dealing with types

// run-time "foo" is always ultimate answer
int foo_runtime(int)
{
    return 42;
}

// compile-time "foo" is factorial
constexpr int foo_compiletime(int num)
{
      return num > 1 ? foo_compiletime(num - 1) * num : 1;
}

Then we need a way to detect that argument is compile time constant expression. If we don't want to use compiler-specific ways like __builtin_constant_p then there are ways to detect it in standard C++ as well. I'm pretty sure that following trick is invented by Johannes Schaub but I can't find the cite. Very nice and clear trick.

template<typename T> 
constexpr typename std::remove_reference<T>::type makeprval(T && t) 
{
    return t;
}

#define isprvalconstexpr(e) noexcept(makeprval(e))

The noexcept operator is required to work compile-time and so branching based on it will be optimized out by most compilers. So now we can write a "foo" macro that selects the algorithm based on argument's constexprness and to test it:

#define foo(X) (isprvalconstexpr(X)?foo_compiletime(X):foo_runtime(X))

int main(int argc, char *argv[])
{
    int a = 1;
    const int b = 2;
    constexpr int c = 3;
    const int d = argc;

    std::cout << foo(a) << std::endl;
    std::cout << foo(b) << std::endl;
    std::cout << foo(c) << std::endl;
    std::cout << foo(d) << std::endl;
}

Expected output is:

42
2
6
42

On the few compilers that I tried it works like expected.

While there is no such thing as "constexpr overloading" in C++11, you can still use GCC/Clang __builtin_constant_p intrinsic. Note, that this optimization is not very useful for double pow(double), because both GCC and Clang already can optimize pow for constant integral exponents, but if you write a multiprecision or vector library, then this optimization should work.

Check this example:

#define my_pow(a, b) (__builtin_constant_p(b) ? optimized_pow(a, b) : generic_pow(a, b))

double generic_pow(double a, double b);

__attribute__((always_inline)) inline double optimized_pow(double a, double b) {
    if (b == 0.0) return 1.0;
    if (b == 1.0) return a;
    if (b == 2.0) return a * a;
    if (b == 3.0) return a * a * a;
    if (b == 4.0) return a * a * a * a;

    return generic_pow(a, b);
}

double test(double a, double b) {
    double x = 2.0 + 2.0;
    return my_pow(a, x) + my_pow(a, b);
}

In this example my_pow(a, x) will be expanded to a*a*a*a (thanks to dead code elimination), and my_pow(a, b) will be expanded to direct generic_pow call without any preliminary checks.

It would have to be overloaded based on the result being constexpr or not, rather than the arguments.

A const std::string could store a pointer to the literal, knowing that it would never be written to (using const_cast to remove const from the std::string would be necessary, and that's already undefined behavior). It'd just be necessary to store a boolean flag to inhibit freeing the buffer during destruction.

But a non-const string, even if initialized from constexpr arguments, requires dynamic allocation, because a writable copy of the argument is required, and therefore a hypothetical constexpr constructor should not be used.

From the standard (section 7.1.6.1 [dcl.type.cv]), modifying any object which was created const is undefined behavior:

Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior.

The problem, as stated, feels wrong.

A std::string, by construction, owns the memory. If you want a simple reference to an existing buffer, you can use something akin to llvm::StringRef:

class StringRef {
public:
  constexpr StringRef(char const* d, size_t s): data(d), size(s) {}

private:
  char const* data;
  size_t size;
};

Of course, there is the bummer that strlen and all the others C functions are not constexpr. This feels like a defect of the Standard (think about all the maths functions...).

As for state, you can (a bit), as long as you understand how to store it. Remember that loops are equivalent to recursions ? Well, likewise, you can "store" state by passing it as argument to a helper function.

// potentially unsafe (non-limited)
constexpr int length(char const* c) {
  return *c == '\0' ? 0 : 1 + length(c+1);
}

// OR a safer version
constexpr int length_helper(char const* c, unsigned limit) {
  return *c == '\0' or limit <= 0 ? 0 : 1 + length_helper(c+1, limit-1);
}

constexpr int length256(char const* c) { return length_helper(c, 256); }

Of course, this form of this state is somewhat limited (you cannot use complicated constructs) and that is a limitation of constexpr. But it's already a huge leap forward. Going further would mean going deeper into purity (which is hardly possible in C++).

Is it possible for a standard-compliant C++11 implementation to allow function overloading based on the arguments being constexpr, or would this require updating the standard? If it is not allowed, was it intentionally not allowed?

If the standard doesn't say you can do something, then allowing someone to do it would be non-standard behavior. And therefore, a compiler that allowed it would be implementing a language extension.

That's not necessarily a bad thing, after all. But it wouldn't be compliant C++11.

We can only guess at the intentions of the standards committee. They may have deliberately not allowed it, or it may have been something of an oversight. The fact is that the standard doesn't overloading is allowed, therefore it isn't.

Another option to detect compile-time compilation using SFINAE: http://coliru.stacked-crooked.com/a/f3a2c11bcccdb5bf

template<typename T>
auto f(const T&)
{
  return 1;
}

constexpr auto f(int)
{
  return 2;
}



////////////////////////////////////////////////////////////////////////
template<typename T, int=f(T{})>
constexpr bool is_f_constexpr_for(int) {return true;}

template<typename...>
constexpr bool is_f_constexpr_for(...) {return false;}



template<typename T>
auto g(const T& t)
{
  if constexpr (is_f_constexpr_for<T>(0))
  {

  }
  else
  {

  }
}

It is possible to identify whether a given static storage variable is a constant expression, using an approach proposed by Richard Smith based on narrowing conversion rules.

We can assign to an unsigned int a consexpr non-negative int without narrowing:

unsigned int u {std::max(0, -3)}; // compiles, max is constexpr

However, we cannot do the above if we use a variable:

int a = 3;
unsigned int u {std::max(0, a)}; // compilation error, narrowing int to unsigned int

To identify whether a given int reference is const expression, we can test whether it can be assigned to an unsigned int without narrowing with either its positive or negative value. This should be possible for any int which value is known at compile time, i.e. can be considered as a constant expression.

template<const int& p> std::true_type
    is_constexpr_impl(decltype((unsigned int){std::max(-p, p)}));
template<const int& p> std::false_type
    is_constexpr_impl(...);
template<const int& p> using is_constexpr =
    decltype(is_constexpr_impl<p>(0));

Now we can have different implementations for runtime and compile time with the macro approach:

int foo_runtime(int num) {
    return num;
}

constexpr int foo_compiletime(int num) {
      return num + 1;
}

#define foo(X) (is_constexpr<X>()?foo_compiletime(X):foo_runtime(X))

And as said, it will mimic an overload for const expression:

int main() {
    static int a = 3;
    static const int b = 42; // considered constexpr
    static const int c = foo_runtime(42); // not constexpr
    static constexpr int d = 4;
    static constexpr int e = -2;
    static int f = 0;
    static const int g = 0; // considered constexpr

    std::cout << foo(a) << std::endl;
    std::cout << foo(b) << std::endl;
    std::cout << foo(c) << std::endl;
    std::cout << foo(d) << std::endl;
    std::cout << foo(e) << std::endl;
    std::cout << foo(f) << std::endl;
    std::cout << foo(g) << std::endl;
}

Above is nice, though not very useful as it is limited to static storage variables. But it does present overloading based on constexpr.

Another approach to achieve the same, without depending on narrowing conversion, can be:

template<const int& p> std::true_type
    is_constexpr_impl(std::array<int, std::max(p, -p)>);
template<const int& p> std::false_type
    is_constexpr_impl(...);
template<const int& p> using is_constexpr = 
    decltype(is_constexpr_impl<p>(0));

The use of std::array above replaces using simple c-array, which doesn't work well for gcc with this approach.

Or another one - again, without relying on narrowing rules - that also works fine:

template<const int& p, typename T = void>
struct is_constexpr: std::false_type {};

template<const int& p>
struct is_constexpr<p, std::void_t<int[std::max(p,-p)+1]>>: std::true_type {};

Note that if we would try to achieve the same with a more simple approach:

template<typename T>
struct is_constexpr: std::false_type {};

template<typename T>
struct is_constexpr<const T>: std::true_type {};

#define foo(X) (is_constexpr<decltype(X)>()?foo_compiletime(X):foo_runtime(X))

We would not achieve our goal for this line:

static const int c = foo_runtime(42); // const but not constexpr

I've been looking for information covering this issue since at least the original post over 12 years ago now. The answer to the question as stated, as far as I know, is no. There also appear to be a few answers that claim to be some kind of solution, but do not solve the problem at all. The best hope of actually solving it that I'm aware of is the following proposal:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1045r1.html

The pow(x, 2) function call example is rather low-hanging, in the sense that a decent compiler sometimes has the capacity to understand the inputs to a function in such a way to optimize it, however, this paper suggests the following template would compile:

template <typename T, size_t N>
class myArray
{
    T arr[N];
public:
    T& operator[](constexpr int i)
    {
        static_assert(i >= 0 && i < N, "Out of bounds index i");
        return arr[i];
    }
};

That would in turn prevent bad runtime code from compiling:

int main()
{
    myArray<int, 2> arr;
    arr[0] = rand(); // OK
    arr[1] = rand(); // OK
    arr[2] = rand(); // ERROR: Out of bounds index i
}