Related: Function returning constexpr does not compile
I feel like constexpr is limited in usefulness in C++11 because of the inability to define two functions that would otherwise have the same signature, but have one be constexpr and the other not constexpr. In other words, it would be very helpful if I could have, for example, a constexpr std::string constructor that takes constexpr arguments only, and a non-constexpr std::string constructor for non-constexpr arguments. Another example would be a theoretically complicated function that could be made more efficient by using state. You can't easily do that with a constexpr function, so you are left with two choices: have a constexpr function that is very slow if you pass in non-constexpr arguments, or give up on constexpr entirely (or write two separate functions, but you may not know which version to call).
My question, therefore, is this:
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?
@NicolBolas: Say I have a function that maps an enum to a std::string. The most straight-forward way to do this, assuming my enum goes from 0 to n - 1, is to create an array of size n filled with the result.
I could create a static constexpr char const * [] and construct a std::string on return (paying the cost of creating a std::string object every time I call the function), or I can create a static std::string const [] and return the value I look up, paying the cost of all of the std::string constructors the first time I call the function. It seems like a better solution would be to create the std::string in memory at compile time (similar to what is done now with char const *), but the only way to do this would be to alert the constructor that it has constexpr arguments.
For a an example other than a std::string constructor, I think it's pretty straight-forward to find an example where, if you could ignore the requirements of constexpr (and thus create a non-constexpr function), you could create a more efficient function. Consider this thread: constexpr question, why do these two different programs run in such a different amount of time with g++?
If I call fib with a constexpr argument, I can't beat do better than the compiler optimizing away the function call entirely. But if I call fib with a non-constexpr argument, I may want to have it call my own version that implements things like memoization (which would require state) so I get run time similar to what would have been my compile time had I passed a constexpr argument.
10 Answers 10
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.
2 Comments
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
constexprfunction 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
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.
1 Comment
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.
6 Comments
foo_runtime() as constexpr. Otherwise, yes, when we need constant expression to be returned then we can't use functions that don't return it. IOW constexpr int fooB = foo_compiletime(b); There are no overloading in C++ based on return type.constexpr is still detectable for static storage, see: stackoverflow.com/a/60714976/2085626 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.
1 Comment
__builtin_constant_p doesn't work on constexpr function arguments.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.
12 Comments
const is not a type; it is a modifier for a type. There is no way for your code to know that it is in a true const std::string instead of just a std::string that just so happens to be const-accessed right now. Without that knowledge, without being able to tell the difference, it is simply not possible to implement this optimization. That's why someone wrote an old boost::const_string class; because there's no way to implement it without specialized code that can detect that it is always constant.const modifier to be applied to constructors.const_cast to modify a const std::string (via pointer or reference, obviously), unless it has external knowledge that the object was not created const. Modifying an object that was created const is already undefined behavior, adding this optimization wouldn't break anything. I've quoted that particular section of the standard.const member functions can't tell whether the object is const, they have to assume it is and not make modifications. The only issue is the destructor.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++).
Comments
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.
2 Comments
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
{
}
}
Comments
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
5 Comments
is_constexpr, i.e. using: (1) narrowing rules, (2) template non-type parameter, (3) array size. Though, all these options work only for static storage variables as they are all based on passing the variable being checked as a template parameter by reference.std::max(x, -x) that works with all types (and INT_MIN) would be (void(expr), 0). It always produces the value 0, but is only a constant expression if the first argument to the comma operator is a constant expression.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
}
Comments
Explore related questions
See similar questions with these tags.
We don’t propose to make constexpr applicable to function arguments because it would be meaningless for non-inline functions (the argument would be a constant, but the function wouldn’t know which) and because it would lead to complications of the overloading rules (can I overload on constexpr-ness? — no).if (is_constexpr (value)) static_assert (condition); else assert (condition);if (is_constexpr (value)) static_assert (condition); else assert (condition);Dead code elimination does not work in such way.