8

I wrote a constexpr function that returns an array.

#include <iostream>

constexpr auto get_str(void)
-> const char(&)[4] {   
    return { 'T', 'E', 'S', 'T' };
}

constexpr int sum(const char(&str)[4]){
    return str[0] + str[1] + str[2] + str[3];
}

int main(void){

    constexpr int s = sum(get_str());

    std::cout << s << std::endl;

    return 0;
}

g++ 4.8 compiles the code correctly, but issues the following warning:

test.cpp: In function ‘constexpr const char (& get_str())[4]’:
test.cpp:5:30: warning: returning reference to temporary [-Wreturn-local-addr]
  return { 'T', 'E', 'S', 'T' };

Is the warning correct in this circumstance? Is it incorrect to return an array from a constexpr function like this even though the function is never actually called at runtime, only during compilation?

Xeno
  • 451
  • 2
  • 13
  • 1
    You can use `std::array` to return a constexpr static array by value, instead of returning a reference. – Mikael Persson Aug 31 '14 at 20:04
  • @MikaelPersson Thanks, I tried using std::array at one point, but my full code is doing some strange things that required a compile-time conversion to const char*, and I couldn't do &arr[0] in a constant expression. – Xeno Aug 31 '14 at 20:18

2 Answers2

2

clang 3.4 does not compile this code since sum(get_str()) is not a constexpr and as far as I can tell clang is correct here, this line (see it live):

constexpr int s = sum(get_str());

generates the following error:

error: constexpr variable 's' must be initialized by a constant expression
constexpr int s = sum(get_str());
              ^   ~~~~~~~~~~~~~~

note: read of temporary whose lifetime has ended
return str[0] + str[1] + str[2] + str[3] 
       ^

It is not a valid constexpr for two reasons. This invokes undefined behavior and this is explicitly disallowed in a constant expression, to summarize the draft C++ standard section 5.19 says:

A conditional-expression e is a core constant expression unless the evaluation of e,

and contains the following bullet:

an operation that would have undefined behavior

which accessing outside of its lifetime would be. We know the lifetime of the temporary is not extended in this case from section 12.2 Temporary objects which says:

The second context is when a reference is bound to a temporary.117 The temporary to which the reference is bound or the temporary that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference except

and includes the following bullet:

The lifetime of a temporary bound to the returned value in a function return statement (6.6.3) is not extended; the temporary is destroyed at the end of the full-expression in the return statement.

So although it is indeed true that a constant expression is not guaranteed to be evaluated at translation, we have a note in section 5.19 Constant expressions that mentions this (emphasis mine going forward):

Note: Constant expressions can be evaluated during translation.—end note ]

Even if it was guaranteed we still would not be allowed to invoke undefined behavior.

The second issue is that constexpr references must be either to objects of static storage duration or functions, cppreference mentions this in its core constant expression section:

Reference constant expression is an lvalue core constant expression that designates an object with static storage duration or a function

and as far as I can tell this is covered in section 5.19 Constant expressions paragraph 4 which says:

each non-static data member of reference type refers to an object with static storage duration or to a function,

Community
  • 1
  • 1
Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
1

the function is never actually called at runtime, only during compilation?

Not guaranteed at all by Standard. The compiler is well within it's rights to invoke it at runtime.

constexpr temporaries never die if the compiler invokes it at compilation time. The compiler is under no obligation.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • It was under no obligation, but It definitely did it at compile time looking at the assembly. I guess the warning is justified though, and if it's not guaranteed I'll avoid doing this. – Xeno Aug 31 '14 at 20:24
  • I know this is old, but I saw this in another question and it is relevant here: "In addition to be able to evaluate expressions at compile time, we want to be able to **require expressions to be evaluated at compile time; constexpr in front of a variable definition does that** (and implies const):" – Xeno Sep 23 '14 at 20:19