When is explicit move needed for a return statement?
In a comment to another question Jonathan Wakely responds to my statement:
You never need explicit move for a local variable function return
value. It's implicit move there
->
... never say never ... You need an explicit move if the local variable
is not the same type as the return type, e.g.std::unique_ptr<base>, but
f() { auto p = std::make_unique<derived>(); p->foo(); return p; }
if the types are the same it will move if possible ...
So it seems sometimes we may have to move a local variable on return.
The example
std::unique_ptr<base> f() {
auto p = std::make_unique<derived>();
p->foo();
return p;
}
is nice in that it gives a compilation error
> prog.cpp:10:14: error: cannot convert ‘p’ from type
> ‘std::unique_ptr<derived>’ to type ‘std::unique_ptr<derived>&&’
but I'm wondering whether there is a good chance to detect this in general -- and is this here a limit of the language rules or of unique_ptr??
c++ c++11 return implicit-conversion move-semantics
edited May 23 '17 at 12:17
Community♦
11
asked Jul 5 '13 at 4:21
Martin BaMartin Ba
19.9k21117248
add a comment |
In a comment to another question Jonathan Wakely responds to my statement:
You never need explicit move for a local variable function return
value. It's implicit move there
->
... never say never ... You need an explicit move if the local variable
is not the same type as the return type, e.g.std::unique_ptr<base>, but
f() { auto p = std::make_unique<derived>(); p->foo(); return p; }
if the types are the same it will move if possible ...
So it seems sometimes we may have to move a local variable on return.
The example
std::unique_ptr<base> f() {
auto p = std::make_unique<derived>();
p->foo();
return p;
}
is nice in that it gives a compilation error
> prog.cpp:10:14: error: cannot convert ‘p’ from type
> ‘std::unique_ptr<derived>’ to type ‘std::unique_ptr<derived>&&’
but I'm wondering whether there is a good chance to detect this in general -- and is this here a limit of the language rules or of unique_ptr??
c++ c++11 return implicit-conversion move-semantics
edited May 23 '17 at 12:17
Community♦
11
asked Jul 5 '13 at 4:21
Martin BaMartin Ba
19.9k21117248
add a comment |
In a comment to another question Jonathan Wakely responds to my statement:
You never need explicit move for a local variable function return
value. It's implicit move there
->
... never say never ... You need an explicit move if the local variable
is not the same type as the return type, e.g.std::unique_ptr<base>, but
f() { auto p = std::make_unique<derived>(); p->foo(); return p; }
if the types are the same it will move if possible ...
So it seems sometimes we may have to move a local variable on return.
The example
std::unique_ptr<base> f() {
auto p = std::make_unique<derived>();
p->foo();
return p;
}
is nice in that it gives a compilation error
> prog.cpp:10:14: error: cannot convert ‘p’ from type
> ‘std::unique_ptr<derived>’ to type ‘std::unique_ptr<derived>&&’
but I'm wondering whether there is a good chance to detect this in general -- and is this here a limit of the language rules or of unique_ptr??
c++ c++11 return implicit-conversion move-semantics
edited May 23 '17 at 12:17
Community♦
11
asked Jul 5 '13 at 4:21
Martin BaMartin Ba
19.9k21117248
In a comment to another question Jonathan Wakely responds to my statement:
You never need explicit move for a local variable function return
value. It's implicit move there
->
... never say never ... You need an explicit move if the local variable
is not the same type as the return type, e.g.std::unique_ptr<base>, but
f() { auto p = std::make_unique<derived>(); p->foo(); return p; }
if the types are the same it will move if possible ...
So it seems sometimes we may have to move a local variable on return.
The example
std::unique_ptr<base> f() {
auto p = std::make_unique<derived>();
p->foo();
return p;
}
is nice in that it gives a compilation error
> prog.cpp:10:14: error: cannot convert ‘p’ from type
> ‘std::unique_ptr<derived>’ to type ‘std::unique_ptr<derived>&&’
but I'm wondering whether there is a good chance to detect this in general -- and is this here a limit of the language rules or of unique_ptr??
c++ c++11 return implicit-conversion move-semantics
c++ c++11 return implicit-conversion move-semantics
edited May 23 '17 at 12:17
Community♦
11
asked Jul 5 '13 at 4:21
Martin BaMartin Ba
19.9k21117248
edited May 23 '17 at 12:17
Community♦
11
asked Jul 5 '13 at 4:21
Martin BaMartin Ba
19.9k21117248
edited May 23 '17 at 12:17
Community♦
11
edited May 23 '17 at 12:17
Community♦
11
edited May 23 '17 at 12:17
Community♦
11
11
asked Jul 5 '13 at 4:21
Martin BaMartin Ba
19.9k21117248
asked Jul 5 '13 at 4:21
Martin BaMartin Ba
19.9k21117248
asked Jul 5 '13 at 4:21
Martin BaMartin Ba
19.9k21117248
19.9k21117248
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Update:
Explicit move should not be needed in modern compiler versions.
Core DR 1579 changed the rules so that the return value will be treated as an rvalue even when the types are not the same. GCC 5 implements the new rule, for C++11 as well as C++14.
Original answer:
This is not a limitation of unique_ptr, it's a limitation of the language, the same limitation applies to any return statement that calls a converting constructor taking an rvalue reference:
struct U { };
struct T {
T(U&&) { }
};
T f() {
U u;
return u; // error, cannot bind lvalue to U&&
}
This will not compile because [class.copy]/32 says:
When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue.
This means that the expression in a return statement can only be treated as an rvalue if it is eligible for copy/move elision (aka NRVO) but that is too restrictive because it means it only applies when the type is exactly the same, even though the variable is always going out of scope so it would be reasonable to always treat is as an rvalue (technically as an xvalue, an expiring value.)
This was recently suggested by Richard Smith (and previously by Xeo) and I think it's a very good idea.
edited May 23 '17 at 12:02
Community♦
11
answered Jul 5 '13 at 7:42
Jonathan WakelyJonathan Wakely
131k16239408
3
I originally sent this suggestion to Mike and Richard a long time ago for consideration in Bristol, but it seems they didn't get to it. :(
– Xeo
Jul 5 '13 at 8:17
2
Oh, and here is the related Core / Evolution issue. Going through my mails again, it seems that Jeffrey Yasskin actually beat me to it. I added the suggestion to also move from subobjects of local variables, though. :)
– Xeo
Jul 5 '13 at 8:43
2
@Xeo A sensible state of an individual object isn't necessarily a sensible state in the context of a larger object which it contains. It certainly shouldn't for public members (as anyone can set them), but there are, with 100% certainty, numerous people who abuse public members and have (hopefully documented) requirements on what they may or may not contain. Therefore such a change could break legacy code.
– Joe
Jul 5 '13 at 11:29
2
The member might not be public, you might be returning it from a friend or member function that can access the object. I agree with @Joe that moving part of an object could break its invariants, so you'd either need a way to explicitly disable the implicit move, or be conservative and not do it for sub-objects
– Jonathan Wakely
Jul 5 '13 at 11:54
3
This should be updated to reflect the resolution of open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
– T.C.
Feb 18 '15 at 7:20
|
show 5 more comments
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%2f17481018%2fwhen-is-explicit-move-needed-for-a-return-statement%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Update:
Explicit move should not be needed in modern compiler versions.
Core DR 1579 changed the rules so that the return value will be treated as an rvalue even when the types are not the same. GCC 5 implements the new rule, for C++11 as well as C++14.
Original answer:
This is not a limitation of unique_ptr, it's a limitation of the language, the same limitation applies to any return statement that calls a converting constructor taking an rvalue reference:
struct U { };
struct T {
T(U&&) { }
};
T f() {
U u;
return u; // error, cannot bind lvalue to U&&
}
This will not compile because [class.copy]/32 says:
When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue.
This means that the expression in a return statement can only be treated as an rvalue if it is eligible for copy/move elision (aka NRVO) but that is too restrictive because it means it only applies when the type is exactly the same, even though the variable is always going out of scope so it would be reasonable to always treat is as an rvalue (technically as an xvalue, an expiring value.)
This was recently suggested by Richard Smith (and previously by Xeo) and I think it's a very good idea.
edited May 23 '17 at 12:02
Community♦
11
answered Jul 5 '13 at 7:42
Jonathan WakelyJonathan Wakely
131k16239408
3
I originally sent this suggestion to Mike and Richard a long time ago for consideration in Bristol, but it seems they didn't get to it. :(
– Xeo
Jul 5 '13 at 8:17
2
Oh, and here is the related Core / Evolution issue. Going through my mails again, it seems that Jeffrey Yasskin actually beat me to it. I added the suggestion to also move from subobjects of local variables, though. :)
– Xeo
Jul 5 '13 at 8:43
2
@Xeo A sensible state of an individual object isn't necessarily a sensible state in the context of a larger object which it contains. It certainly shouldn't for public members (as anyone can set them), but there are, with 100% certainty, numerous people who abuse public members and have (hopefully documented) requirements on what they may or may not contain. Therefore such a change could break legacy code.
– Joe
Jul 5 '13 at 11:29
2
The member might not be public, you might be returning it from a friend or member function that can access the object. I agree with @Joe that moving part of an object could break its invariants, so you'd either need a way to explicitly disable the implicit move, or be conservative and not do it for sub-objects
– Jonathan Wakely
Jul 5 '13 at 11:54
3
This should be updated to reflect the resolution of open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
– T.C.
Feb 18 '15 at 7:20
|
show 5 more comments
Update:
Explicit move should not be needed in modern compiler versions.
Core DR 1579 changed the rules so that the return value will be treated as an rvalue even when the types are not the same. GCC 5 implements the new rule, for C++11 as well as C++14.
Original answer:
This is not a limitation of unique_ptr, it's a limitation of the language, the same limitation applies to any return statement that calls a converting constructor taking an rvalue reference:
struct U { };
struct T {
T(U&&) { }
};
T f() {
U u;
return u; // error, cannot bind lvalue to U&&
}
This will not compile because [class.copy]/32 says:
When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue.
This means that the expression in a return statement can only be treated as an rvalue if it is eligible for copy/move elision (aka NRVO) but that is too restrictive because it means it only applies when the type is exactly the same, even though the variable is always going out of scope so it would be reasonable to always treat is as an rvalue (technically as an xvalue, an expiring value.)
This was recently suggested by Richard Smith (and previously by Xeo) and I think it's a very good idea.
edited May 23 '17 at 12:02
Community♦
11
answered Jul 5 '13 at 7:42
Jonathan WakelyJonathan Wakely
131k16239408
3
I originally sent this suggestion to Mike and Richard a long time ago for consideration in Bristol, but it seems they didn't get to it. :(
– Xeo
Jul 5 '13 at 8:17
2
Oh, and here is the related Core / Evolution issue. Going through my mails again, it seems that Jeffrey Yasskin actually beat me to it. I added the suggestion to also move from subobjects of local variables, though. :)
– Xeo
Jul 5 '13 at 8:43
2
@Xeo A sensible state of an individual object isn't necessarily a sensible state in the context of a larger object which it contains. It certainly shouldn't for public members (as anyone can set them), but there are, with 100% certainty, numerous people who abuse public members and have (hopefully documented) requirements on what they may or may not contain. Therefore such a change could break legacy code.
– Joe
Jul 5 '13 at 11:29
2
The member might not be public, you might be returning it from a friend or member function that can access the object. I agree with @Joe that moving part of an object could break its invariants, so you'd either need a way to explicitly disable the implicit move, or be conservative and not do it for sub-objects
– Jonathan Wakely
Jul 5 '13 at 11:54
3
This should be updated to reflect the resolution of open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
– T.C.
Feb 18 '15 at 7:20
|
show 5 more comments
Update:
Explicit move should not be needed in modern compiler versions.
Core DR 1579 changed the rules so that the return value will be treated as an rvalue even when the types are not the same. GCC 5 implements the new rule, for C++11 as well as C++14.
Original answer:
This is not a limitation of unique_ptr, it's a limitation of the language, the same limitation applies to any return statement that calls a converting constructor taking an rvalue reference:
struct U { };
struct T {
T(U&&) { }
};
T f() {
U u;
return u; // error, cannot bind lvalue to U&&
}
This will not compile because [class.copy]/32 says:
When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue.
This means that the expression in a return statement can only be treated as an rvalue if it is eligible for copy/move elision (aka NRVO) but that is too restrictive because it means it only applies when the type is exactly the same, even though the variable is always going out of scope so it would be reasonable to always treat is as an rvalue (technically as an xvalue, an expiring value.)
This was recently suggested by Richard Smith (and previously by Xeo) and I think it's a very good idea.
edited May 23 '17 at 12:02
Community♦
11
answered Jul 5 '13 at 7:42
Jonathan WakelyJonathan Wakely
131k16239408
Update:
Explicit move should not be needed in modern compiler versions.
Core DR 1579 changed the rules so that the return value will be treated as an rvalue even when the types are not the same. GCC 5 implements the new rule, for C++11 as well as C++14.
Original answer:
This is not a limitation of unique_ptr, it's a limitation of the language, the same limitation applies to any return statement that calls a converting constructor taking an rvalue reference:
struct U { };
struct T {
T(U&&) { }
};
T f() {
U u;
return u; // error, cannot bind lvalue to U&&
}
This will not compile because [class.copy]/32 says:
When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue.
This means that the expression in a return statement can only be treated as an rvalue if it is eligible for copy/move elision (aka NRVO) but that is too restrictive because it means it only applies when the type is exactly the same, even though the variable is always going out of scope so it would be reasonable to always treat is as an rvalue (technically as an xvalue, an expiring value.)
This was recently suggested by Richard Smith (and previously by Xeo) and I think it's a very good idea.
edited May 23 '17 at 12:02
Community♦
11
answered Jul 5 '13 at 7:42
Jonathan WakelyJonathan Wakely
131k16239408
edited May 23 '17 at 12:02
Community♦
11
edited May 23 '17 at 12:02
Community♦
11
edited May 23 '17 at 12:02
Community♦
11
11
answered Jul 5 '13 at 7:42
Jonathan WakelyJonathan Wakely
131k16239408
answered Jul 5 '13 at 7:42
Jonathan WakelyJonathan Wakely
131k16239408
answered Jul 5 '13 at 7:42
Jonathan WakelyJonathan Wakely
131k16239408
131k16239408
3
I originally sent this suggestion to Mike and Richard a long time ago for consideration in Bristol, but it seems they didn't get to it. :(
– Xeo
Jul 5 '13 at 8:17
2
Oh, and here is the related Core / Evolution issue. Going through my mails again, it seems that Jeffrey Yasskin actually beat me to it. I added the suggestion to also move from subobjects of local variables, though. :)
– Xeo
Jul 5 '13 at 8:43
2
@Xeo A sensible state of an individual object isn't necessarily a sensible state in the context of a larger object which it contains. It certainly shouldn't for public members (as anyone can set them), but there are, with 100% certainty, numerous people who abuse public members and have (hopefully documented) requirements on what they may or may not contain. Therefore such a change could break legacy code.
– Joe
Jul 5 '13 at 11:29
2
The member might not be public, you might be returning it from a friend or member function that can access the object. I agree with @Joe that moving part of an object could break its invariants, so you'd either need a way to explicitly disable the implicit move, or be conservative and not do it for sub-objects
– Jonathan Wakely
Jul 5 '13 at 11:54
3
This should be updated to reflect the resolution of open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
– T.C.
Feb 18 '15 at 7:20
|
show 5 more comments
3
I originally sent this suggestion to Mike and Richard a long time ago for consideration in Bristol, but it seems they didn't get to it. :(
– Xeo
Jul 5 '13 at 8:17
2
Oh, and here is the related Core / Evolution issue. Going through my mails again, it seems that Jeffrey Yasskin actually beat me to it. I added the suggestion to also move from subobjects of local variables, though. :)
– Xeo
Jul 5 '13 at 8:43
2
@Xeo A sensible state of an individual object isn't necessarily a sensible state in the context of a larger object which it contains. It certainly shouldn't for public members (as anyone can set them), but there are, with 100% certainty, numerous people who abuse public members and have (hopefully documented) requirements on what they may or may not contain. Therefore such a change could break legacy code.
– Joe
Jul 5 '13 at 11:29
2
The member might not be public, you might be returning it from a friend or member function that can access the object. I agree with @Joe that moving part of an object could break its invariants, so you'd either need a way to explicitly disable the implicit move, or be conservative and not do it for sub-objects
– Jonathan Wakely
Jul 5 '13 at 11:54
3
This should be updated to reflect the resolution of open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
– T.C.
Feb 18 '15 at 7:20
3
3
I originally sent this suggestion to Mike and Richard a long time ago for consideration in Bristol, but it seems they didn't get to it. :(
– Xeo
Jul 5 '13 at 8:17
I originally sent this suggestion to Mike and Richard a long time ago for consideration in Bristol, but it seems they didn't get to it. :(
– Xeo
Jul 5 '13 at 8:17
2
2
Oh, and here is the related Core / Evolution issue. Going through my mails again, it seems that Jeffrey Yasskin actually beat me to it. I added the suggestion to also move from subobjects of local variables, though. :)
– Xeo
Jul 5 '13 at 8:43
Oh, and here is the related Core / Evolution issue. Going through my mails again, it seems that Jeffrey Yasskin actually beat me to it. I added the suggestion to also move from subobjects of local variables, though. :)
– Xeo
Jul 5 '13 at 8:43
2
2
@Xeo A sensible state of an individual object isn't necessarily a sensible state in the context of a larger object which it contains. It certainly shouldn't for public members (as anyone can set them), but there are, with 100% certainty, numerous people who abuse public members and have (hopefully documented) requirements on what they may or may not contain. Therefore such a change could break legacy code.
– Joe
Jul 5 '13 at 11:29
@Xeo A sensible state of an individual object isn't necessarily a sensible state in the context of a larger object which it contains. It certainly shouldn't for public members (as anyone can set them), but there are, with 100% certainty, numerous people who abuse public members and have (hopefully documented) requirements on what they may or may not contain. Therefore such a change could break legacy code.
– Joe
Jul 5 '13 at 11:29
2
2
The member might not be public, you might be returning it from a friend or member function that can access the object. I agree with @Joe that moving part of an object could break its invariants, so you'd either need a way to explicitly disable the implicit move, or be conservative and not do it for sub-objects
– Jonathan Wakely
Jul 5 '13 at 11:54
The member might not be public, you might be returning it from a friend or member function that can access the object. I agree with @Joe that moving part of an object could break its invariants, so you'd either need a way to explicitly disable the implicit move, or be conservative and not do it for sub-objects
– Jonathan Wakely
Jul 5 '13 at 11:54
3
3
This should be updated to reflect the resolution of open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
– T.C.
Feb 18 '15 at 7:20
This should be updated to reflect the resolution of open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
– T.C.
Feb 18 '15 at 7:20
|
show 5 more comments
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%2f17481018%2fwhen-is-explicit-move-needed-for-a-return-statement%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
