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.











share|improve this question























  • 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















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.











share|improve this question























  • 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













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.











share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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

















  • 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













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 or emplace_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 the emplace_front and emplace_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 original emplace proposal that they do not.







share|improve this answer



























    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.






    share|improve this answer




















    • 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










    • @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










    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',
    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
    );



    );













     

    draft saved


    draft discarded


















    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

























    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 or emplace_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 the emplace_front and emplace_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 original emplace proposal that they do not.







    share|improve this answer
























      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 or emplace_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 the emplace_front and emplace_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 original emplace proposal that they do not.







      share|improve this answer






















        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 or emplace_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 the emplace_front and emplace_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 original emplace proposal that they do not.







        share|improve this answer












        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 or emplace_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 the emplace_front and emplace_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 original emplace proposal that they do not.








        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 10 at 15:06









        xskxzr

        5,65582051




        5,65582051






















            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.






            share|improve this answer




















            • 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










            • @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














            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.






            share|improve this answer




















            • 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










            • @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












            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.






            share|improve this answer












            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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 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










            • @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










            • @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















            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

















             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Top Tejano songwriter Luis Silva dead of heart attack at 64

            ReactJS Fetched API data displays live - need Data displayed static

            Evgeni Malkin