Why doesn't a const reference extend the life of a temporary object passed via a function?Why use “b < a ? a : b” instead of “a < b ? b : a” to implement max template?How come a non-const reference cannot bind to a temporary object?Does a const reference class member prolong the life of a temporary?How do I achieve the theoretical maximum of 4 FLOPs per cycle?Why not non-const reference to temporary objects?Temporary object and non-const referenceconst reference to temporary referenceC++11 scoping and lifetime of temporary bound to a (const) reference (GCC)Why am I using the deleted function 'void std::ref(const _Tp&&) [with _Tp = int]'Can a Second Const Reference Extend the Lifetime of a TemporaryExtending the life of a temporary object by getting a reference to a subobject
Typesetting a double Over Dot on top of a symbol
How can I add custom success page
Why airport relocation isn't done gradually?
Domain expired, GoDaddy holds it and is asking more money
Symmetry in quantum mechanics
Manga about a female worker who got dragged into another world together with this high school girl and she was just told she's not needed anymore
COUNT(*) or MAX(id) - which is faster?
Is "plugging out" electronic devices an American expression?
Doomsday-clock for my fantasy planet
Email Account under attack (really) - anything I can do?
What is the command to reset a PC without deleting any files
What causes the sudden spool-up sound from an F-16 when enabling afterburner?
Does it makes sense to buy a new cycle to learn riding?
Why did the Germans forbid the possession of pet pigeons in Rostov-on-Don in 1941?
Can I find out the caloric content of bread by dehydrating it?
Is ipsum/ipsa/ipse a third person pronoun, or can it serve other functions?
How to make payment on the internet without leaving a money trail?
Patience, young "Padovan"
What does "enim et" mean?
What does 'script /dev/null' do?
How to manage monthly salary
When blogging recipes, how can I support both readers who want the narrative/journey and ones who want the printer-friendly recipe?
Pristine Bit Checking
"listening to me about as much as you're listening to this pole here"
Why doesn't a const reference extend the life of a temporary object passed via a function?
Why use “b < a ? a : b” instead of “a < b ? b : a” to implement max template?How come a non-const reference cannot bind to a temporary object?Does a const reference class member prolong the life of a temporary?How do I achieve the theoretical maximum of 4 FLOPs per cycle?Why not non-const reference to temporary objects?Temporary object and non-const referenceconst reference to temporary referenceC++11 scoping and lifetime of temporary bound to a (const) reference (GCC)Why am I using the deleted function 'void std::ref(const _Tp&&) [with _Tp = int]'Can a Second Const Reference Extend the Lifetime of a TemporaryExtending the life of a temporary object by getting a reference to a subobject
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
In the following simple example, why can't ref2
be bound to the result of min(x,y+1)
?
#include <cstdio>
template< typename T > const T& min(const T& a, const T& b) return a < b ? a : b ;
int main()
int x = 10, y = 2;
const int& ref = min(x,y); //OK
const int& ref2 = min(x,y+1); //NOT OK, WHY?
return ref2; // Compiles to return 0
live example - produces:
main:
xor eax, eax
ret
c++ language-lawyer temporary-objects
|
show 4 more comments
In the following simple example, why can't ref2
be bound to the result of min(x,y+1)
?
#include <cstdio>
template< typename T > const T& min(const T& a, const T& b) return a < b ? a : b ;
int main()
int x = 10, y = 2;
const int& ref = min(x,y); //OK
const int& ref2 = min(x,y+1); //NOT OK, WHY?
return ref2; // Compiles to return 0
live example - produces:
main:
xor eax, eax
ret
c++ language-lawyer temporary-objects
7
This program produces no output and exits with code 0. With-O3
optimization flag all the statements inside of main are discarded.
– VTT
21 hours ago
3
What error does it give?
– fredrik
21 hours ago
5
This is actually a very interesting question. I'll tag language lawyer and hope one of the chiefs picks this one up. I've neither the time nor the expertise. It's all to do with the fact that lifetime extension is not transitive, and where the original objects are located. Go on @StoryTeller.
– Bathsheba
21 hours ago
4
@Bathsheba Could you quickly explain whyb < a ? b : a
that advantageous?
– lubgr
21 hours ago
4
@Michiel The thing is, if the binding was direct (e.g. ifmin
was returning by value),ref2
would extend the lifetime of the bound temporary to that of itself. Hence the question, I guess.
– Angew
21 hours ago
|
show 4 more comments
In the following simple example, why can't ref2
be bound to the result of min(x,y+1)
?
#include <cstdio>
template< typename T > const T& min(const T& a, const T& b) return a < b ? a : b ;
int main()
int x = 10, y = 2;
const int& ref = min(x,y); //OK
const int& ref2 = min(x,y+1); //NOT OK, WHY?
return ref2; // Compiles to return 0
live example - produces:
main:
xor eax, eax
ret
c++ language-lawyer temporary-objects
In the following simple example, why can't ref2
be bound to the result of min(x,y+1)
?
#include <cstdio>
template< typename T > const T& min(const T& a, const T& b) return a < b ? a : b ;
int main()
int x = 10, y = 2;
const int& ref = min(x,y); //OK
const int& ref2 = min(x,y+1); //NOT OK, WHY?
return ref2; // Compiles to return 0
live example - produces:
main:
xor eax, eax
ret
c++ language-lawyer temporary-objects
c++ language-lawyer temporary-objects
edited 14 hours ago
Boann
37.4k1290122
37.4k1290122
asked 21 hours ago
Khurshid NormuradovKhurshid Normuradov
402310
402310
7
This program produces no output and exits with code 0. With-O3
optimization flag all the statements inside of main are discarded.
– VTT
21 hours ago
3
What error does it give?
– fredrik
21 hours ago
5
This is actually a very interesting question. I'll tag language lawyer and hope one of the chiefs picks this one up. I've neither the time nor the expertise. It's all to do with the fact that lifetime extension is not transitive, and where the original objects are located. Go on @StoryTeller.
– Bathsheba
21 hours ago
4
@Bathsheba Could you quickly explain whyb < a ? b : a
that advantageous?
– lubgr
21 hours ago
4
@Michiel The thing is, if the binding was direct (e.g. ifmin
was returning by value),ref2
would extend the lifetime of the bound temporary to that of itself. Hence the question, I guess.
– Angew
21 hours ago
|
show 4 more comments
7
This program produces no output and exits with code 0. With-O3
optimization flag all the statements inside of main are discarded.
– VTT
21 hours ago
3
What error does it give?
– fredrik
21 hours ago
5
This is actually a very interesting question. I'll tag language lawyer and hope one of the chiefs picks this one up. I've neither the time nor the expertise. It's all to do with the fact that lifetime extension is not transitive, and where the original objects are located. Go on @StoryTeller.
– Bathsheba
21 hours ago
4
@Bathsheba Could you quickly explain whyb < a ? b : a
that advantageous?
– lubgr
21 hours ago
4
@Michiel The thing is, if the binding was direct (e.g. ifmin
was returning by value),ref2
would extend the lifetime of the bound temporary to that of itself. Hence the question, I guess.
– Angew
21 hours ago
7
7
This program produces no output and exits with code 0. With
-O3
optimization flag all the statements inside of main are discarded.– VTT
21 hours ago
This program produces no output and exits with code 0. With
-O3
optimization flag all the statements inside of main are discarded.– VTT
21 hours ago
3
3
What error does it give?
– fredrik
21 hours ago
What error does it give?
– fredrik
21 hours ago
5
5
This is actually a very interesting question. I'll tag language lawyer and hope one of the chiefs picks this one up. I've neither the time nor the expertise. It's all to do with the fact that lifetime extension is not transitive, and where the original objects are located. Go on @StoryTeller.
– Bathsheba
21 hours ago
This is actually a very interesting question. I'll tag language lawyer and hope one of the chiefs picks this one up. I've neither the time nor the expertise. It's all to do with the fact that lifetime extension is not transitive, and where the original objects are located. Go on @StoryTeller.
– Bathsheba
21 hours ago
4
4
@Bathsheba Could you quickly explain why
b < a ? b : a
that advantageous?– lubgr
21 hours ago
@Bathsheba Could you quickly explain why
b < a ? b : a
that advantageous?– lubgr
21 hours ago
4
4
@Michiel The thing is, if the binding was direct (e.g. if
min
was returning by value), ref2
would extend the lifetime of the bound temporary to that of itself. Hence the question, I guess.– Angew
21 hours ago
@Michiel The thing is, if the binding was direct (e.g. if
min
was returning by value), ref2
would extend the lifetime of the bound temporary to that of itself. Hence the question, I guess.– Angew
21 hours ago
|
show 4 more comments
3 Answers
3
active
oldest
votes
It's by design. In a nutshell, only the named reference to which the temporary is bound directly will extend its lifetime.
[class.temporary]
5 There are three contexts in which temporaries are destroyed at a
different point than the end of the full-expression. [...]
6 The third context is when a reference is bound to a temporary.
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:
- A temporary object bound to a reference parameter in a function call persists until the completion of the full-expression containing
the call.
- The lifetime of a temporary bound to the returned value in a function return statement is not extended; the temporary is destroyed
at the end of the full-expression in the return statement.
- [...]
You didn't bind directly to ref2
, and you even pass it via a return statement. The standard explicitly says it won't extend the lifetime. In part to make certain optimizations possible. But ultimately, because keeping track of which temporary should be extended when a reference is passed in and out of functions is intractable in general.
Since compilers may optimize aggressively on the assumption that your program exhibits no undefined behavior, you see a possible manifestation of that. Accessing a value outside its lifetime is undefined, this is what return ref2;
does, and since the behavior is undefined, simply returning zero is a valid behavior to exhibit. No contract is broken by the compiler.
Thx a lot. I wrongly thought that,y+1
temporary object bind tob
and it's live extends via return function. .
– Khurshid Normuradov
19 hours ago
add a comment |
This is intentional. A reference can only extend the lifetime of a temporary when it is bound to that temporary directly. In your code, you are binding ref2
to the result of min
, which is a reference. It doesn't matter that that reference references a temporary. Only b
extends the lifetime of the temporary; it doesn't matter that ref2
also refers to that same temporary.
Another way to look at it: You can't optionally have lifetime extension. It's a static property. If ref2
would do the Correct Thingtm, then depending on the runtime values of x
and y+1
the lifetime is extended or not. Not something the compiler is able to do.
add a comment |
I will answer the question first, and then provide some context for the answer. The current working draft contains the following wording:
The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if the glvalue to which the reference is bound was obtained through one of the following:
- a temporary materialization conversion ([conv.rval]),
(
expression)
, where expression is one of these expressions,
- subscripting ([expr.sub]) of an array operand, where that operand is one of these expressions,
- a class member access ([expr.ref]) using the
.
operator where the left operand is one of these expressions and the right operand designates a non-static data member of non-reference type,
- a pointer-to-member operation ([expr.mptr.oper]) using the
.*
operator where the left operand is one of these expressions and the right operand is a pointer to data member of non-reference type,
- a
const_cast
([expr.const.cast]),static_cast
([expr.static.cast]),dynamic_cast
([expr.dynamic.cast]), orreinterpret_cast
([expr.reinterpret.cast])
converting, without a user-defined conversion, a glvalue operand that is one of these expressions to a glvalue that refers to the object designated by the operand, or to its complete object or a subobject thereof,
- a conditional expression ([expr.cond]) that is a glvalue where the second or third operand is one of these expressions, or
- a comma expression ([expr.comma]) that is a glvalue where the right operand is one of these expressions.
According to this, when a reference is bound to a glvalue returned from a function call, lifetime extension does not occur, because the glvalue was obtained from the function call, which is not one of the permitted expressions for lifetime extension.
The lifetime of the y+1
temporary is extended once when bound to the reference parameter b
. Here, the prvalue y+1
is materialized to yield an xvalue, and the reference is bound to the result of the temporary materialization conversion; lifetime extension thus occurs. When the min
function returns, however, ref2
is bound to the result of the call, and lifetime extension does not occur here. Therefore, the y+1
temporary is destroyed at the end of the definition of ref2
, and ref2
becomes a dangling reference.
There has historically been some confusion on this topic. It is well-known that the OP's code and similar code result in a dangling reference, but the standard text, even as of C++17, did not provide an unambiguous explanation as to why.
It is often claimed that lifetime extension only applies when the reference binds "directly" to the temporary, but the standard has never said anything to that effect. Indeed, the standard defines what it means for a reference to "bind directly", and that definition (e.g., const std::string& s = "foo";
is an indirect reference binding) is clearly not relevant here.
Rakete1111 has said in a comment elsewhere on SO that lifetime extension only applies when the reference binds to a prvalue (rather than some glvalue that was obtained through a previous reference binding to that temporary object); they appear to be saying something similar here by "bound ... directly". However, there is no textual support for this theory. Indeed, code like the following has sometimes been considered to trigger lifetime extension:
struct S int x; ;
const int& r = S42.x;
However, in C++14, the expression S42.x
became an xvalue, so if lifetime extension applies here, then it is not because the reference binds to a prvalue.
One might instead claim that lifetime extension only applies once, and binding any other references to the same object do not further extend its lifetime. This would explain why the OP's code creates a dangling reference, without preventing lifetime extension in the S42.x
case. However, there is no statement to this effect in the standard, either.
StoryTeller has also said here that the reference must bind directly, but I don't know what he means by that, either. He cites standards text indicating that binding a reference to a temporary in a return
statement doesn't extend its lifetime. However, that statement seems to be intended to apply to the case where the temporary in question is created by the full-expression in the return
statement, since it says the temporary will be destroyed at the end of that full-expression. Clearly that's not the case for the y+1
temporary, which will instead be destroyed at the end of the full-expression containing the call to min
. Thus, I tend to think that this statement was not intended to apply to cases like that in the question. Instead, its effect, together with the other limitations on lifetime extension, is to prevent any temporary object's lifetime from being extended beyond the block scope in which it was created. But this would not prevent the y+1
temporary in the question from surviving until the end of main
.
Thus the question remains: what is the principle that explains why the binding of ref2
to the temporary in the question doesn't extend that temporary's lifetime?
The wording from the current working draft that I cited earlier was introduced by the resolution of CWG 1299, which was opened in 2011 but only resolved recently (not in time for C++17). In a sense, it clarifies the intuition that the reference must bind "directly", by delineating those cases where the binding is "direct" enough for lifetime extension to occur; it is not, however, so restrictive as to only allow it when the reference binds to a prvalue. It permits lifetime extension in the S42.x
case.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55567962%2fwhy-doesnt-a-const-reference-extend-the-life-of-a-temporary-object-passed-via-a%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's by design. In a nutshell, only the named reference to which the temporary is bound directly will extend its lifetime.
[class.temporary]
5 There are three contexts in which temporaries are destroyed at a
different point than the end of the full-expression. [...]
6 The third context is when a reference is bound to a temporary.
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:
- A temporary object bound to a reference parameter in a function call persists until the completion of the full-expression containing
the call.
- The lifetime of a temporary bound to the returned value in a function return statement is not extended; the temporary is destroyed
at the end of the full-expression in the return statement.
- [...]
You didn't bind directly to ref2
, and you even pass it via a return statement. The standard explicitly says it won't extend the lifetime. In part to make certain optimizations possible. But ultimately, because keeping track of which temporary should be extended when a reference is passed in and out of functions is intractable in general.
Since compilers may optimize aggressively on the assumption that your program exhibits no undefined behavior, you see a possible manifestation of that. Accessing a value outside its lifetime is undefined, this is what return ref2;
does, and since the behavior is undefined, simply returning zero is a valid behavior to exhibit. No contract is broken by the compiler.
Thx a lot. I wrongly thought that,y+1
temporary object bind tob
and it's live extends via return function. .
– Khurshid Normuradov
19 hours ago
add a comment |
It's by design. In a nutshell, only the named reference to which the temporary is bound directly will extend its lifetime.
[class.temporary]
5 There are three contexts in which temporaries are destroyed at a
different point than the end of the full-expression. [...]
6 The third context is when a reference is bound to a temporary.
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:
- A temporary object bound to a reference parameter in a function call persists until the completion of the full-expression containing
the call.
- The lifetime of a temporary bound to the returned value in a function return statement is not extended; the temporary is destroyed
at the end of the full-expression in the return statement.
- [...]
You didn't bind directly to ref2
, and you even pass it via a return statement. The standard explicitly says it won't extend the lifetime. In part to make certain optimizations possible. But ultimately, because keeping track of which temporary should be extended when a reference is passed in and out of functions is intractable in general.
Since compilers may optimize aggressively on the assumption that your program exhibits no undefined behavior, you see a possible manifestation of that. Accessing a value outside its lifetime is undefined, this is what return ref2;
does, and since the behavior is undefined, simply returning zero is a valid behavior to exhibit. No contract is broken by the compiler.
Thx a lot. I wrongly thought that,y+1
temporary object bind tob
and it's live extends via return function. .
– Khurshid Normuradov
19 hours ago
add a comment |
It's by design. In a nutshell, only the named reference to which the temporary is bound directly will extend its lifetime.
[class.temporary]
5 There are three contexts in which temporaries are destroyed at a
different point than the end of the full-expression. [...]
6 The third context is when a reference is bound to a temporary.
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:
- A temporary object bound to a reference parameter in a function call persists until the completion of the full-expression containing
the call.
- The lifetime of a temporary bound to the returned value in a function return statement is not extended; the temporary is destroyed
at the end of the full-expression in the return statement.
- [...]
You didn't bind directly to ref2
, and you even pass it via a return statement. The standard explicitly says it won't extend the lifetime. In part to make certain optimizations possible. But ultimately, because keeping track of which temporary should be extended when a reference is passed in and out of functions is intractable in general.
Since compilers may optimize aggressively on the assumption that your program exhibits no undefined behavior, you see a possible manifestation of that. Accessing a value outside its lifetime is undefined, this is what return ref2;
does, and since the behavior is undefined, simply returning zero is a valid behavior to exhibit. No contract is broken by the compiler.
It's by design. In a nutshell, only the named reference to which the temporary is bound directly will extend its lifetime.
[class.temporary]
5 There are three contexts in which temporaries are destroyed at a
different point than the end of the full-expression. [...]
6 The third context is when a reference is bound to a temporary.
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:
- A temporary object bound to a reference parameter in a function call persists until the completion of the full-expression containing
the call.
- The lifetime of a temporary bound to the returned value in a function return statement is not extended; the temporary is destroyed
at the end of the full-expression in the return statement.
- [...]
You didn't bind directly to ref2
, and you even pass it via a return statement. The standard explicitly says it won't extend the lifetime. In part to make certain optimizations possible. But ultimately, because keeping track of which temporary should be extended when a reference is passed in and out of functions is intractable in general.
Since compilers may optimize aggressively on the assumption that your program exhibits no undefined behavior, you see a possible manifestation of that. Accessing a value outside its lifetime is undefined, this is what return ref2;
does, and since the behavior is undefined, simply returning zero is a valid behavior to exhibit. No contract is broken by the compiler.
edited 21 hours ago
answered 21 hours ago
StoryTellerStoryTeller
105k13220284
105k13220284
Thx a lot. I wrongly thought that,y+1
temporary object bind tob
and it's live extends via return function. .
– Khurshid Normuradov
19 hours ago
add a comment |
Thx a lot. I wrongly thought that,y+1
temporary object bind tob
and it's live extends via return function. .
– Khurshid Normuradov
19 hours ago
Thx a lot. I wrongly thought that,
y+1
temporary object bind to b
and it's live extends via return function. .– Khurshid Normuradov
19 hours ago
Thx a lot. I wrongly thought that,
y+1
temporary object bind to b
and it's live extends via return function. .– Khurshid Normuradov
19 hours ago
add a comment |
This is intentional. A reference can only extend the lifetime of a temporary when it is bound to that temporary directly. In your code, you are binding ref2
to the result of min
, which is a reference. It doesn't matter that that reference references a temporary. Only b
extends the lifetime of the temporary; it doesn't matter that ref2
also refers to that same temporary.
Another way to look at it: You can't optionally have lifetime extension. It's a static property. If ref2
would do the Correct Thingtm, then depending on the runtime values of x
and y+1
the lifetime is extended or not. Not something the compiler is able to do.
add a comment |
This is intentional. A reference can only extend the lifetime of a temporary when it is bound to that temporary directly. In your code, you are binding ref2
to the result of min
, which is a reference. It doesn't matter that that reference references a temporary. Only b
extends the lifetime of the temporary; it doesn't matter that ref2
also refers to that same temporary.
Another way to look at it: You can't optionally have lifetime extension. It's a static property. If ref2
would do the Correct Thingtm, then depending on the runtime values of x
and y+1
the lifetime is extended or not. Not something the compiler is able to do.
add a comment |
This is intentional. A reference can only extend the lifetime of a temporary when it is bound to that temporary directly. In your code, you are binding ref2
to the result of min
, which is a reference. It doesn't matter that that reference references a temporary. Only b
extends the lifetime of the temporary; it doesn't matter that ref2
also refers to that same temporary.
Another way to look at it: You can't optionally have lifetime extension. It's a static property. If ref2
would do the Correct Thingtm, then depending on the runtime values of x
and y+1
the lifetime is extended or not. Not something the compiler is able to do.
This is intentional. A reference can only extend the lifetime of a temporary when it is bound to that temporary directly. In your code, you are binding ref2
to the result of min
, which is a reference. It doesn't matter that that reference references a temporary. Only b
extends the lifetime of the temporary; it doesn't matter that ref2
also refers to that same temporary.
Another way to look at it: You can't optionally have lifetime extension. It's a static property. If ref2
would do the Correct Thingtm, then depending on the runtime values of x
and y+1
the lifetime is extended or not. Not something the compiler is able to do.
answered 21 hours ago
Rakete1111Rakete1111
35.3k1084120
35.3k1084120
add a comment |
add a comment |
I will answer the question first, and then provide some context for the answer. The current working draft contains the following wording:
The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if the glvalue to which the reference is bound was obtained through one of the following:
- a temporary materialization conversion ([conv.rval]),
(
expression)
, where expression is one of these expressions,
- subscripting ([expr.sub]) of an array operand, where that operand is one of these expressions,
- a class member access ([expr.ref]) using the
.
operator where the left operand is one of these expressions and the right operand designates a non-static data member of non-reference type,
- a pointer-to-member operation ([expr.mptr.oper]) using the
.*
operator where the left operand is one of these expressions and the right operand is a pointer to data member of non-reference type,
- a
const_cast
([expr.const.cast]),static_cast
([expr.static.cast]),dynamic_cast
([expr.dynamic.cast]), orreinterpret_cast
([expr.reinterpret.cast])
converting, without a user-defined conversion, a glvalue operand that is one of these expressions to a glvalue that refers to the object designated by the operand, or to its complete object or a subobject thereof,
- a conditional expression ([expr.cond]) that is a glvalue where the second or third operand is one of these expressions, or
- a comma expression ([expr.comma]) that is a glvalue where the right operand is one of these expressions.
According to this, when a reference is bound to a glvalue returned from a function call, lifetime extension does not occur, because the glvalue was obtained from the function call, which is not one of the permitted expressions for lifetime extension.
The lifetime of the y+1
temporary is extended once when bound to the reference parameter b
. Here, the prvalue y+1
is materialized to yield an xvalue, and the reference is bound to the result of the temporary materialization conversion; lifetime extension thus occurs. When the min
function returns, however, ref2
is bound to the result of the call, and lifetime extension does not occur here. Therefore, the y+1
temporary is destroyed at the end of the definition of ref2
, and ref2
becomes a dangling reference.
There has historically been some confusion on this topic. It is well-known that the OP's code and similar code result in a dangling reference, but the standard text, even as of C++17, did not provide an unambiguous explanation as to why.
It is often claimed that lifetime extension only applies when the reference binds "directly" to the temporary, but the standard has never said anything to that effect. Indeed, the standard defines what it means for a reference to "bind directly", and that definition (e.g., const std::string& s = "foo";
is an indirect reference binding) is clearly not relevant here.
Rakete1111 has said in a comment elsewhere on SO that lifetime extension only applies when the reference binds to a prvalue (rather than some glvalue that was obtained through a previous reference binding to that temporary object); they appear to be saying something similar here by "bound ... directly". However, there is no textual support for this theory. Indeed, code like the following has sometimes been considered to trigger lifetime extension:
struct S int x; ;
const int& r = S42.x;
However, in C++14, the expression S42.x
became an xvalue, so if lifetime extension applies here, then it is not because the reference binds to a prvalue.
One might instead claim that lifetime extension only applies once, and binding any other references to the same object do not further extend its lifetime. This would explain why the OP's code creates a dangling reference, without preventing lifetime extension in the S42.x
case. However, there is no statement to this effect in the standard, either.
StoryTeller has also said here that the reference must bind directly, but I don't know what he means by that, either. He cites standards text indicating that binding a reference to a temporary in a return
statement doesn't extend its lifetime. However, that statement seems to be intended to apply to the case where the temporary in question is created by the full-expression in the return
statement, since it says the temporary will be destroyed at the end of that full-expression. Clearly that's not the case for the y+1
temporary, which will instead be destroyed at the end of the full-expression containing the call to min
. Thus, I tend to think that this statement was not intended to apply to cases like that in the question. Instead, its effect, together with the other limitations on lifetime extension, is to prevent any temporary object's lifetime from being extended beyond the block scope in which it was created. But this would not prevent the y+1
temporary in the question from surviving until the end of main
.
Thus the question remains: what is the principle that explains why the binding of ref2
to the temporary in the question doesn't extend that temporary's lifetime?
The wording from the current working draft that I cited earlier was introduced by the resolution of CWG 1299, which was opened in 2011 but only resolved recently (not in time for C++17). In a sense, it clarifies the intuition that the reference must bind "directly", by delineating those cases where the binding is "direct" enough for lifetime extension to occur; it is not, however, so restrictive as to only allow it when the reference binds to a prvalue. It permits lifetime extension in the S42.x
case.
add a comment |
I will answer the question first, and then provide some context for the answer. The current working draft contains the following wording:
The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if the glvalue to which the reference is bound was obtained through one of the following:
- a temporary materialization conversion ([conv.rval]),
(
expression)
, where expression is one of these expressions,
- subscripting ([expr.sub]) of an array operand, where that operand is one of these expressions,
- a class member access ([expr.ref]) using the
.
operator where the left operand is one of these expressions and the right operand designates a non-static data member of non-reference type,
- a pointer-to-member operation ([expr.mptr.oper]) using the
.*
operator where the left operand is one of these expressions and the right operand is a pointer to data member of non-reference type,
- a
const_cast
([expr.const.cast]),static_cast
([expr.static.cast]),dynamic_cast
([expr.dynamic.cast]), orreinterpret_cast
([expr.reinterpret.cast])
converting, without a user-defined conversion, a glvalue operand that is one of these expressions to a glvalue that refers to the object designated by the operand, or to its complete object or a subobject thereof,
- a conditional expression ([expr.cond]) that is a glvalue where the second or third operand is one of these expressions, or
- a comma expression ([expr.comma]) that is a glvalue where the right operand is one of these expressions.
According to this, when a reference is bound to a glvalue returned from a function call, lifetime extension does not occur, because the glvalue was obtained from the function call, which is not one of the permitted expressions for lifetime extension.
The lifetime of the y+1
temporary is extended once when bound to the reference parameter b
. Here, the prvalue y+1
is materialized to yield an xvalue, and the reference is bound to the result of the temporary materialization conversion; lifetime extension thus occurs. When the min
function returns, however, ref2
is bound to the result of the call, and lifetime extension does not occur here. Therefore, the y+1
temporary is destroyed at the end of the definition of ref2
, and ref2
becomes a dangling reference.
There has historically been some confusion on this topic. It is well-known that the OP's code and similar code result in a dangling reference, but the standard text, even as of C++17, did not provide an unambiguous explanation as to why.
It is often claimed that lifetime extension only applies when the reference binds "directly" to the temporary, but the standard has never said anything to that effect. Indeed, the standard defines what it means for a reference to "bind directly", and that definition (e.g., const std::string& s = "foo";
is an indirect reference binding) is clearly not relevant here.
Rakete1111 has said in a comment elsewhere on SO that lifetime extension only applies when the reference binds to a prvalue (rather than some glvalue that was obtained through a previous reference binding to that temporary object); they appear to be saying something similar here by "bound ... directly". However, there is no textual support for this theory. Indeed, code like the following has sometimes been considered to trigger lifetime extension:
struct S int x; ;
const int& r = S42.x;
However, in C++14, the expression S42.x
became an xvalue, so if lifetime extension applies here, then it is not because the reference binds to a prvalue.
One might instead claim that lifetime extension only applies once, and binding any other references to the same object do not further extend its lifetime. This would explain why the OP's code creates a dangling reference, without preventing lifetime extension in the S42.x
case. However, there is no statement to this effect in the standard, either.
StoryTeller has also said here that the reference must bind directly, but I don't know what he means by that, either. He cites standards text indicating that binding a reference to a temporary in a return
statement doesn't extend its lifetime. However, that statement seems to be intended to apply to the case where the temporary in question is created by the full-expression in the return
statement, since it says the temporary will be destroyed at the end of that full-expression. Clearly that's not the case for the y+1
temporary, which will instead be destroyed at the end of the full-expression containing the call to min
. Thus, I tend to think that this statement was not intended to apply to cases like that in the question. Instead, its effect, together with the other limitations on lifetime extension, is to prevent any temporary object's lifetime from being extended beyond the block scope in which it was created. But this would not prevent the y+1
temporary in the question from surviving until the end of main
.
Thus the question remains: what is the principle that explains why the binding of ref2
to the temporary in the question doesn't extend that temporary's lifetime?
The wording from the current working draft that I cited earlier was introduced by the resolution of CWG 1299, which was opened in 2011 but only resolved recently (not in time for C++17). In a sense, it clarifies the intuition that the reference must bind "directly", by delineating those cases where the binding is "direct" enough for lifetime extension to occur; it is not, however, so restrictive as to only allow it when the reference binds to a prvalue. It permits lifetime extension in the S42.x
case.
add a comment |
I will answer the question first, and then provide some context for the answer. The current working draft contains the following wording:
The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if the glvalue to which the reference is bound was obtained through one of the following:
- a temporary materialization conversion ([conv.rval]),
(
expression)
, where expression is one of these expressions,
- subscripting ([expr.sub]) of an array operand, where that operand is one of these expressions,
- a class member access ([expr.ref]) using the
.
operator where the left operand is one of these expressions and the right operand designates a non-static data member of non-reference type,
- a pointer-to-member operation ([expr.mptr.oper]) using the
.*
operator where the left operand is one of these expressions and the right operand is a pointer to data member of non-reference type,
- a
const_cast
([expr.const.cast]),static_cast
([expr.static.cast]),dynamic_cast
([expr.dynamic.cast]), orreinterpret_cast
([expr.reinterpret.cast])
converting, without a user-defined conversion, a glvalue operand that is one of these expressions to a glvalue that refers to the object designated by the operand, or to its complete object or a subobject thereof,
- a conditional expression ([expr.cond]) that is a glvalue where the second or third operand is one of these expressions, or
- a comma expression ([expr.comma]) that is a glvalue where the right operand is one of these expressions.
According to this, when a reference is bound to a glvalue returned from a function call, lifetime extension does not occur, because the glvalue was obtained from the function call, which is not one of the permitted expressions for lifetime extension.
The lifetime of the y+1
temporary is extended once when bound to the reference parameter b
. Here, the prvalue y+1
is materialized to yield an xvalue, and the reference is bound to the result of the temporary materialization conversion; lifetime extension thus occurs. When the min
function returns, however, ref2
is bound to the result of the call, and lifetime extension does not occur here. Therefore, the y+1
temporary is destroyed at the end of the definition of ref2
, and ref2
becomes a dangling reference.
There has historically been some confusion on this topic. It is well-known that the OP's code and similar code result in a dangling reference, but the standard text, even as of C++17, did not provide an unambiguous explanation as to why.
It is often claimed that lifetime extension only applies when the reference binds "directly" to the temporary, but the standard has never said anything to that effect. Indeed, the standard defines what it means for a reference to "bind directly", and that definition (e.g., const std::string& s = "foo";
is an indirect reference binding) is clearly not relevant here.
Rakete1111 has said in a comment elsewhere on SO that lifetime extension only applies when the reference binds to a prvalue (rather than some glvalue that was obtained through a previous reference binding to that temporary object); they appear to be saying something similar here by "bound ... directly". However, there is no textual support for this theory. Indeed, code like the following has sometimes been considered to trigger lifetime extension:
struct S int x; ;
const int& r = S42.x;
However, in C++14, the expression S42.x
became an xvalue, so if lifetime extension applies here, then it is not because the reference binds to a prvalue.
One might instead claim that lifetime extension only applies once, and binding any other references to the same object do not further extend its lifetime. This would explain why the OP's code creates a dangling reference, without preventing lifetime extension in the S42.x
case. However, there is no statement to this effect in the standard, either.
StoryTeller has also said here that the reference must bind directly, but I don't know what he means by that, either. He cites standards text indicating that binding a reference to a temporary in a return
statement doesn't extend its lifetime. However, that statement seems to be intended to apply to the case where the temporary in question is created by the full-expression in the return
statement, since it says the temporary will be destroyed at the end of that full-expression. Clearly that's not the case for the y+1
temporary, which will instead be destroyed at the end of the full-expression containing the call to min
. Thus, I tend to think that this statement was not intended to apply to cases like that in the question. Instead, its effect, together with the other limitations on lifetime extension, is to prevent any temporary object's lifetime from being extended beyond the block scope in which it was created. But this would not prevent the y+1
temporary in the question from surviving until the end of main
.
Thus the question remains: what is the principle that explains why the binding of ref2
to the temporary in the question doesn't extend that temporary's lifetime?
The wording from the current working draft that I cited earlier was introduced by the resolution of CWG 1299, which was opened in 2011 but only resolved recently (not in time for C++17). In a sense, it clarifies the intuition that the reference must bind "directly", by delineating those cases where the binding is "direct" enough for lifetime extension to occur; it is not, however, so restrictive as to only allow it when the reference binds to a prvalue. It permits lifetime extension in the S42.x
case.
I will answer the question first, and then provide some context for the answer. The current working draft contains the following wording:
The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if the glvalue to which the reference is bound was obtained through one of the following:
- a temporary materialization conversion ([conv.rval]),
(
expression)
, where expression is one of these expressions,
- subscripting ([expr.sub]) of an array operand, where that operand is one of these expressions,
- a class member access ([expr.ref]) using the
.
operator where the left operand is one of these expressions and the right operand designates a non-static data member of non-reference type,
- a pointer-to-member operation ([expr.mptr.oper]) using the
.*
operator where the left operand is one of these expressions and the right operand is a pointer to data member of non-reference type,
- a
const_cast
([expr.const.cast]),static_cast
([expr.static.cast]),dynamic_cast
([expr.dynamic.cast]), orreinterpret_cast
([expr.reinterpret.cast])
converting, without a user-defined conversion, a glvalue operand that is one of these expressions to a glvalue that refers to the object designated by the operand, or to its complete object or a subobject thereof,
- a conditional expression ([expr.cond]) that is a glvalue where the second or third operand is one of these expressions, or
- a comma expression ([expr.comma]) that is a glvalue where the right operand is one of these expressions.
According to this, when a reference is bound to a glvalue returned from a function call, lifetime extension does not occur, because the glvalue was obtained from the function call, which is not one of the permitted expressions for lifetime extension.
The lifetime of the y+1
temporary is extended once when bound to the reference parameter b
. Here, the prvalue y+1
is materialized to yield an xvalue, and the reference is bound to the result of the temporary materialization conversion; lifetime extension thus occurs. When the min
function returns, however, ref2
is bound to the result of the call, and lifetime extension does not occur here. Therefore, the y+1
temporary is destroyed at the end of the definition of ref2
, and ref2
becomes a dangling reference.
There has historically been some confusion on this topic. It is well-known that the OP's code and similar code result in a dangling reference, but the standard text, even as of C++17, did not provide an unambiguous explanation as to why.
It is often claimed that lifetime extension only applies when the reference binds "directly" to the temporary, but the standard has never said anything to that effect. Indeed, the standard defines what it means for a reference to "bind directly", and that definition (e.g., const std::string& s = "foo";
is an indirect reference binding) is clearly not relevant here.
Rakete1111 has said in a comment elsewhere on SO that lifetime extension only applies when the reference binds to a prvalue (rather than some glvalue that was obtained through a previous reference binding to that temporary object); they appear to be saying something similar here by "bound ... directly". However, there is no textual support for this theory. Indeed, code like the following has sometimes been considered to trigger lifetime extension:
struct S int x; ;
const int& r = S42.x;
However, in C++14, the expression S42.x
became an xvalue, so if lifetime extension applies here, then it is not because the reference binds to a prvalue.
One might instead claim that lifetime extension only applies once, and binding any other references to the same object do not further extend its lifetime. This would explain why the OP's code creates a dangling reference, without preventing lifetime extension in the S42.x
case. However, there is no statement to this effect in the standard, either.
StoryTeller has also said here that the reference must bind directly, but I don't know what he means by that, either. He cites standards text indicating that binding a reference to a temporary in a return
statement doesn't extend its lifetime. However, that statement seems to be intended to apply to the case where the temporary in question is created by the full-expression in the return
statement, since it says the temporary will be destroyed at the end of that full-expression. Clearly that's not the case for the y+1
temporary, which will instead be destroyed at the end of the full-expression containing the call to min
. Thus, I tend to think that this statement was not intended to apply to cases like that in the question. Instead, its effect, together with the other limitations on lifetime extension, is to prevent any temporary object's lifetime from being extended beyond the block scope in which it was created. But this would not prevent the y+1
temporary in the question from surviving until the end of main
.
Thus the question remains: what is the principle that explains why the binding of ref2
to the temporary in the question doesn't extend that temporary's lifetime?
The wording from the current working draft that I cited earlier was introduced by the resolution of CWG 1299, which was opened in 2011 but only resolved recently (not in time for C++17). In a sense, it clarifies the intuition that the reference must bind "directly", by delineating those cases where the binding is "direct" enough for lifetime extension to occur; it is not, however, so restrictive as to only allow it when the reference binds to a prvalue. It permits lifetime extension in the S42.x
case.
answered 13 hours ago
BrianBrian
66.7k798191
66.7k798191
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55567962%2fwhy-doesnt-a-const-reference-extend-the-life-of-a-temporary-object-passed-via-a%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
7
This program produces no output and exits with code 0. With
-O3
optimization flag all the statements inside of main are discarded.– VTT
21 hours ago
3
What error does it give?
– fredrik
21 hours ago
5
This is actually a very interesting question. I'll tag language lawyer and hope one of the chiefs picks this one up. I've neither the time nor the expertise. It's all to do with the fact that lifetime extension is not transitive, and where the original objects are located. Go on @StoryTeller.
– Bathsheba
21 hours ago
4
@Bathsheba Could you quickly explain why
b < a ? b : a
that advantageous?– lubgr
21 hours ago
4
@Michiel The thing is, if the binding was direct (e.g. if
min
was returning by value),ref2
would extend the lifetime of the bound temporary to that of itself. Hence the question, I guess.– Angew
21 hours ago