What is the usecase of return value for std::vector::emplace_back in C++17?
up vote
2
down vote
favorite
I have read in cppreference.com that the new(since C++17) std::vector::emplace_back
has an return value of referance to the inserted element.
Return value
- (none) (until C++17)
- A reference to the inserted element. (since C++17)
I was thinking, while inserting element to the vector, why we need a referance to it? how this could be usful or what is the usecase case of this new return?
Here is a sample code which I wrote to see, the feature.
#include <vector>
int main()
std::vector<int> myVec;
for(int i = 0; i < 3; ++i)
int& newElement = myVec.emplace_back(i);
^^^^^^^ => why standard should expose the element after inserting.
c++ c++17 stdvector emplace
add a comment |
up vote
2
down vote
favorite
I have read in cppreference.com that the new(since C++17) std::vector::emplace_back
has an return value of referance to the inserted element.
Return value
- (none) (until C++17)
- A reference to the inserted element. (since C++17)
I was thinking, while inserting element to the vector, why we need a referance to it? how this could be usful or what is the usecase case of this new return?
Here is a sample code which I wrote to see, the feature.
#include <vector>
int main()
std::vector<int> myVec;
for(int i = 0; i < 3; ++i)
int& newElement = myVec.emplace_back(i);
^^^^^^^ => why standard should expose the element after inserting.
c++ c++17 stdvector emplace
You may want to use it afterwards (call a method, return it from a function, use anything that's not done by the constructor)
– UnholySheep
Nov 10 at 14:50
@UnholySheep Could you show me an example case? I could not get it. I have also made a code to see it, which I will post. But I do not know any usecases.
– Const
Nov 10 at 14:54
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I have read in cppreference.com that the new(since C++17) std::vector::emplace_back
has an return value of referance to the inserted element.
Return value
- (none) (until C++17)
- A reference to the inserted element. (since C++17)
I was thinking, while inserting element to the vector, why we need a referance to it? how this could be usful or what is the usecase case of this new return?
Here is a sample code which I wrote to see, the feature.
#include <vector>
int main()
std::vector<int> myVec;
for(int i = 0; i < 3; ++i)
int& newElement = myVec.emplace_back(i);
^^^^^^^ => why standard should expose the element after inserting.
c++ c++17 stdvector emplace
I have read in cppreference.com that the new(since C++17) std::vector::emplace_back
has an return value of referance to the inserted element.
Return value
- (none) (until C++17)
- A reference to the inserted element. (since C++17)
I was thinking, while inserting element to the vector, why we need a referance to it? how this could be usful or what is the usecase case of this new return?
Here is a sample code which I wrote to see, the feature.
#include <vector>
int main()
std::vector<int> myVec;
for(int i = 0; i < 3; ++i)
int& newElement = myVec.emplace_back(i);
^^^^^^^ => why standard should expose the element after inserting.
c++ c++17 stdvector emplace
c++ c++17 stdvector emplace
edited Nov 10 at 14:57
asked Nov 10 at 14:47
Const
687
687
You may want to use it afterwards (call a method, return it from a function, use anything that's not done by the constructor)
– UnholySheep
Nov 10 at 14:50
@UnholySheep Could you show me an example case? I could not get it. I have also made a code to see it, which I will post. But I do not know any usecases.
– Const
Nov 10 at 14:54
add a comment |
You may want to use it afterwards (call a method, return it from a function, use anything that's not done by the constructor)
– UnholySheep
Nov 10 at 14:50
@UnholySheep Could you show me an example case? I could not get it. I have also made a code to see it, which I will post. But I do not know any usecases.
– Const
Nov 10 at 14:54
You may want to use it afterwards (call a method, return it from a function, use anything that's not done by the constructor)
– UnholySheep
Nov 10 at 14:50
You may want to use it afterwards (call a method, return it from a function, use anything that's not done by the constructor)
– UnholySheep
Nov 10 at 14:50
@UnholySheep Could you show me an example case? I could not get it. I have also made a code to see it, which I will post. But I do not know any usecases.
– Const
Nov 10 at 14:54
@UnholySheep Could you show me an example case? I could not get it. I have also made a code to see it, which I will post. But I do not know any usecases.
– Const
Nov 10 at 14:54
add a comment |
2 Answers
2
active
oldest
votes
up vote
7
down vote
accepted
The change is made by P0084. The motivation the author gives is
I often find myself wanting to create an element of a container using
emplace_front
oremplace_back
, and then access that element, either to modify it further or simply to use it. So I find myself writing code like this:my_container.emplace_back(...);
my_container.back().do_something(...);
Or perhaps:
my_container.emplace_back(...);
do_something_else(my_container.back());
Quite a common specific case is where I need to construct an object before I have all the
information necessary to put it into its final state, such as when I’m reading it from a file:my_container.emplace_back(); // Default construct.
my_container.back().read(file_stream); // Read the object.
This happens often enough that I tend to write little templates that call some version of
emplace
and return back, which seems rather unnecessary to me. I believe theemplace_front
andemplace_back
functions should return a non-const reference to the newly created element, in keeping with the current Standard Library trend of returning useful information when practical. It was an oversight (on my part) in the originalemplace
proposal that they do not.
add a comment |
up vote
4
down vote
std::cout << vec.emplace_back(7);
it is just convience so you can do more than one thing in an expression.
vec.emplace_back().reg();
anything done by it can be replicated by
(void(vec.emplace_back()), vec.back()).reg();
in pre-C++17 versions (void here is future-proofing parnoia)
It is a common pattern to create an object and use it right away; the return value makes it slightly easier.
I have got your first point. What do you mean by the replication of newemplace_back()
? did you mean, before C++17, this had to be done by first inserting to the container and thenvec.back()
to access the last inserted one?
– Const
Nov 10 at 15:10
@Const Yes. The point is that it saves a call toback()
, which is purely for convenience, and is commonly useful IMO.
– Asu
Nov 10 at 15:13
@Asu Yes, the other answer made it more clear by providing the reference. I wish I could accept both.
– Const
Nov 10 at 15:16
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
accepted
The change is made by P0084. The motivation the author gives is
I often find myself wanting to create an element of a container using
emplace_front
oremplace_back
, and then access that element, either to modify it further or simply to use it. So I find myself writing code like this:my_container.emplace_back(...);
my_container.back().do_something(...);
Or perhaps:
my_container.emplace_back(...);
do_something_else(my_container.back());
Quite a common specific case is where I need to construct an object before I have all the
information necessary to put it into its final state, such as when I’m reading it from a file:my_container.emplace_back(); // Default construct.
my_container.back().read(file_stream); // Read the object.
This happens often enough that I tend to write little templates that call some version of
emplace
and return back, which seems rather unnecessary to me. I believe theemplace_front
andemplace_back
functions should return a non-const reference to the newly created element, in keeping with the current Standard Library trend of returning useful information when practical. It was an oversight (on my part) in the originalemplace
proposal that they do not.
add a comment |
up vote
7
down vote
accepted
The change is made by P0084. The motivation the author gives is
I often find myself wanting to create an element of a container using
emplace_front
oremplace_back
, and then access that element, either to modify it further or simply to use it. So I find myself writing code like this:my_container.emplace_back(...);
my_container.back().do_something(...);
Or perhaps:
my_container.emplace_back(...);
do_something_else(my_container.back());
Quite a common specific case is where I need to construct an object before I have all the
information necessary to put it into its final state, such as when I’m reading it from a file:my_container.emplace_back(); // Default construct.
my_container.back().read(file_stream); // Read the object.
This happens often enough that I tend to write little templates that call some version of
emplace
and return back, which seems rather unnecessary to me. I believe theemplace_front
andemplace_back
functions should return a non-const reference to the newly created element, in keeping with the current Standard Library trend of returning useful information when practical. It was an oversight (on my part) in the originalemplace
proposal that they do not.
add a comment |
up vote
7
down vote
accepted
up vote
7
down vote
accepted
The change is made by P0084. The motivation the author gives is
I often find myself wanting to create an element of a container using
emplace_front
oremplace_back
, and then access that element, either to modify it further or simply to use it. So I find myself writing code like this:my_container.emplace_back(...);
my_container.back().do_something(...);
Or perhaps:
my_container.emplace_back(...);
do_something_else(my_container.back());
Quite a common specific case is where I need to construct an object before I have all the
information necessary to put it into its final state, such as when I’m reading it from a file:my_container.emplace_back(); // Default construct.
my_container.back().read(file_stream); // Read the object.
This happens often enough that I tend to write little templates that call some version of
emplace
and return back, which seems rather unnecessary to me. I believe theemplace_front
andemplace_back
functions should return a non-const reference to the newly created element, in keeping with the current Standard Library trend of returning useful information when practical. It was an oversight (on my part) in the originalemplace
proposal that they do not.
The change is made by P0084. The motivation the author gives is
I often find myself wanting to create an element of a container using
emplace_front
oremplace_back
, and then access that element, either to modify it further or simply to use it. So I find myself writing code like this:my_container.emplace_back(...);
my_container.back().do_something(...);
Or perhaps:
my_container.emplace_back(...);
do_something_else(my_container.back());
Quite a common specific case is where I need to construct an object before I have all the
information necessary to put it into its final state, such as when I’m reading it from a file:my_container.emplace_back(); // Default construct.
my_container.back().read(file_stream); // Read the object.
This happens often enough that I tend to write little templates that call some version of
emplace
and return back, which seems rather unnecessary to me. I believe theemplace_front
andemplace_back
functions should return a non-const reference to the newly created element, in keeping with the current Standard Library trend of returning useful information when practical. It was an oversight (on my part) in the originalemplace
proposal that they do not.
answered Nov 10 at 15:06
xskxzr
5,65582051
5,65582051
add a comment |
add a comment |
up vote
4
down vote
std::cout << vec.emplace_back(7);
it is just convience so you can do more than one thing in an expression.
vec.emplace_back().reg();
anything done by it can be replicated by
(void(vec.emplace_back()), vec.back()).reg();
in pre-C++17 versions (void here is future-proofing parnoia)
It is a common pattern to create an object and use it right away; the return value makes it slightly easier.
I have got your first point. What do you mean by the replication of newemplace_back()
? did you mean, before C++17, this had to be done by first inserting to the container and thenvec.back()
to access the last inserted one?
– Const
Nov 10 at 15:10
@Const Yes. The point is that it saves a call toback()
, which is purely for convenience, and is commonly useful IMO.
– Asu
Nov 10 at 15:13
@Asu Yes, the other answer made it more clear by providing the reference. I wish I could accept both.
– Const
Nov 10 at 15:16
add a comment |
up vote
4
down vote
std::cout << vec.emplace_back(7);
it is just convience so you can do more than one thing in an expression.
vec.emplace_back().reg();
anything done by it can be replicated by
(void(vec.emplace_back()), vec.back()).reg();
in pre-C++17 versions (void here is future-proofing parnoia)
It is a common pattern to create an object and use it right away; the return value makes it slightly easier.
I have got your first point. What do you mean by the replication of newemplace_back()
? did you mean, before C++17, this had to be done by first inserting to the container and thenvec.back()
to access the last inserted one?
– Const
Nov 10 at 15:10
@Const Yes. The point is that it saves a call toback()
, which is purely for convenience, and is commonly useful IMO.
– Asu
Nov 10 at 15:13
@Asu Yes, the other answer made it more clear by providing the reference. I wish I could accept both.
– Const
Nov 10 at 15:16
add a comment |
up vote
4
down vote
up vote
4
down vote
std::cout << vec.emplace_back(7);
it is just convience so you can do more than one thing in an expression.
vec.emplace_back().reg();
anything done by it can be replicated by
(void(vec.emplace_back()), vec.back()).reg();
in pre-C++17 versions (void here is future-proofing parnoia)
It is a common pattern to create an object and use it right away; the return value makes it slightly easier.
std::cout << vec.emplace_back(7);
it is just convience so you can do more than one thing in an expression.
vec.emplace_back().reg();
anything done by it can be replicated by
(void(vec.emplace_back()), vec.back()).reg();
in pre-C++17 versions (void here is future-proofing parnoia)
It is a common pattern to create an object and use it right away; the return value makes it slightly easier.
answered Nov 10 at 15:03
Yakk - Adam Nevraumont
177k19182363
177k19182363
I have got your first point. What do you mean by the replication of newemplace_back()
? did you mean, before C++17, this had to be done by first inserting to the container and thenvec.back()
to access the last inserted one?
– Const
Nov 10 at 15:10
@Const Yes. The point is that it saves a call toback()
, which is purely for convenience, and is commonly useful IMO.
– Asu
Nov 10 at 15:13
@Asu Yes, the other answer made it more clear by providing the reference. I wish I could accept both.
– Const
Nov 10 at 15:16
add a comment |
I have got your first point. What do you mean by the replication of newemplace_back()
? did you mean, before C++17, this had to be done by first inserting to the container and thenvec.back()
to access the last inserted one?
– Const
Nov 10 at 15:10
@Const Yes. The point is that it saves a call toback()
, which is purely for convenience, and is commonly useful IMO.
– Asu
Nov 10 at 15:13
@Asu Yes, the other answer made it more clear by providing the reference. I wish I could accept both.
– Const
Nov 10 at 15:16
I have got your first point. What do you mean by the replication of new
emplace_back()
? did you mean, before C++17, this had to be done by first inserting to the container and then vec.back()
to access the last inserted one?– Const
Nov 10 at 15:10
I have got your first point. What do you mean by the replication of new
emplace_back()
? did you mean, before C++17, this had to be done by first inserting to the container and then vec.back()
to access the last inserted one?– Const
Nov 10 at 15:10
@Const Yes. The point is that it saves a call to
back()
, which is purely for convenience, and is commonly useful IMO.– Asu
Nov 10 at 15:13
@Const Yes. The point is that it saves a call to
back()
, which is purely for convenience, and is commonly useful IMO.– Asu
Nov 10 at 15:13
@Asu Yes, the other answer made it more clear by providing the reference. I wish I could accept both.
– Const
Nov 10 at 15:16
@Asu Yes, the other answer made it more clear by providing the reference. I wish I could accept both.
– Const
Nov 10 at 15:16
add a comment |
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%2f53240086%2fwhat-is-the-usecase-of-return-value-for-stdvectoremplace-back-in-c17%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
You may want to use it afterwards (call a method, return it from a function, use anything that's not done by the constructor)
– UnholySheep
Nov 10 at 14:50
@UnholySheep Could you show me an example case? I could not get it. I have also made a code to see it, which I will post. But I do not know any usecases.
– Const
Nov 10 at 14:54