11–20 of 41 posts
Reddit discussion: https://www.reddit.com/r/cpp/comments/5zzurr/c_value_categor...
I'd love it if someone could shed some light on my question here: https://www.reddit.com/r/cpp/comments/5zzurr/c_value_categor... int const &f(int const &a) { return a; } int r = f(3); Is the value of r implementation-defined according to the standard?
I think this is similar to the std::max/std::min stuff
Earlier quoted context omitted.
I'd love it if someone could shed some light on my question here: https://www.reddit.com/r/cpp/comments/5zzurr/c_value_categor... int const &f(int const &a) { return a; } int r = f(3); Is the value of r implementation-defined according to the standard?
This might answer that https://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-th... I think this is similar to the std::max/std::min stuff
Reddit discussion: https://www.reddit.com/r/cpp/comments/5zzurr/c_value_categor...
I'd love it if someone could shed some light on my question here: https://www.reddit.com/r/cpp/comments/5zzurr/c_value_categor... int const &f(int const &a) { return a; } int r = f(3); Is the value of r implementation-defined according to the standard?
Or have I suddenly gone blind by looking at C++ code one too many times? :)
A comment on the document's design: The low contrast of light gray text on yellow background makes it difficult to read. Black text on white, or dark gray text on white is perfectly acceptable. Another drawback of colored backgrounds is that readers wanting to print out the pdf will consume ink/toner to render the non-white background.
Earlier quoted context omitted.
I'd love it if someone could shed some light on my question here: https://www.reddit.com/r/cpp/comments/5zzurr/c_value_categor... int const &f(int const &a) { return a; } int r = f(3); Is the value of r implementation-defined according to the standard?
I don't see a problem here. r receives a copy of a, not a reference to anything. Or have I suddenly gone blind by looking at C++ code one too many times? :)
Earlier quoted context omitted.
I don't see a problem here. r receives a copy of a, not a reference to anything. Or have I suddenly gone blind by looking at C++ code one too many times? :)
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 temporary can (implementation-defined) be destroyed already.
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.
Earlier quoted context omitted.
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 temporary can (implementation-defined) be destroyed already.
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.
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++. :)
A comment on the document's design: The low contrast of light gray text on yellow background makes it difficult to read. Black text on white, or dark gray text on white is perfectly acceptable. Another drawback of colored backgrounds is that readers wanting to print out the pdf will consume ink/toner to render the non-white background.
I'm pretty sure the author was trying to use the Solarized color scheme: http://ethanschoonover.com/solarized
Earlier quoted context omitted.
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.
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/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…
"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?