4 ms·

If the lifetime of the temporary holding the value 3 can (implementation-defined) be limited to the body of the function, the assignment to r happens when the t

• fauigerzigerk 10y ago
  Ah, now I see what you mean. This is not a problem. The temporary ceases to exist after the function call expression. Copying the return value has to be done before that, otherwise you could never return the value of any local variable.
  • Jare 10y ago
    That's what I had always thought would happen; it makes sense. However, if I'm reading things correctly, the posted article disagrees, and this link also disagrees: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p013... "It is implementation-defined whether the lifetime of a parameter ends when the function in which it is defined returns or at the end of the enclosing full-expression." Hence why I asked for some substantive clarification or solid interpretation of the standard. "Common sense" doesn't cut it with C++. :)
    • fauigerzigerk 10y ago
      I'm not sure where you see a disagreement with section 5.2.2/4 of the standard: "It is implementation-defined whether the lifetime of a parameter ends when the function in which it is defined returns or at the end of the enclosing full-expression." Regardless of where exactly the lifetime of the temporary ends (end of function or end of expression), your example would be correct and not UB. I don't think it is in dispute whether or not the return expression inside the function is evaluated before the lifetime of the parameter ends, but that is when the copy of a into r is made. Where do you see a disagreement with the posted article?
      • Jare 10y ago
        If the lifetime of the temporary ended with the function body, the assignment (which reads the temporary via the returned reference) happens afterwards and that's UB. Essentially, int const &r = f(3); and int r = f(3); would both be UB under that implementation-defined case. The posted article, second row of "common mistakes", describes returning a const reference parameter, when called with a prvalue, as blanket UB. Finally someone clarified: https://timsong-cpp.github.io/cppwp/class.temporary#6.1 https://timsong-cpp.github.io/cppwp/class.temporary#6.1 "6.1 A temporary object bound to a reference parameter in a function call persists until the completion of the full-expression containing the call." So, while the parameter's (the reference "int const &a") lifetime is implementation-defined, the temporary to which that parameter refers to is the full expression of the call. Sanity is restored.
        • fauigerzigerk 10y ago
          You're right, good point.
        • Jeaye 10y ago
          Thanks for digging into this. I'll update that example to be more clear about keeping an lvalue reference to the return value.
        • MaulingMonkey 10y ago
          Just to help bring things home: const int& f(int parameter) { return parameter; } const int i = f(42); Is strictly undefined behavior under the simpler C++03 rules/wording of 5.2.2/4: "The lifetime of a parameter ends when the function in which it is defined returns.") P0135R0 would loosen the requirements on parameter's lifetime as a means of enabling guaranteed copy elision, in such a way that an implementation could technically decide to make this to have defined behavior (not that I suggest relying on it!)