Why try_emplace is not implemented for std::multimap











up vote
6
down vote

favorite












c++17 introduces try_emplace method for std::map, so now I can write code like below



struct Test

{

    Test(int i, int j){}

};

std::map<int, Test> tmap;

tmap.try_emplace(10, 10, 10);


but there is no try_emplace for std::multimap, so piecewise_construct is still needed.



Is there a technical reason for this?






c++ c++17







share|improve this question




















  • 1




    std::multimap does not need try_emplace as it always inserts, so emplace is enough.
    – Slava
    4 hours ago










  • I see, but it's really handy if piecewise_construct can be get rid of for std::multimap
    – Lei Yu
    37 mins ago















up vote
6
down vote

favorite












c++17 introduces try_emplace method for std::map, so now I can write code like below



struct Test

{

    Test(int i, int j){}

};

std::map<int, Test> tmap;

tmap.try_emplace(10, 10, 10);


but there is no try_emplace for std::multimap, so piecewise_construct is still needed.



Is there a technical reason for this?






c++ c++17







share|improve this question




















  • 1




    std::multimap does not need try_emplace as it always inserts, so emplace is enough.
    – Slava
    4 hours ago










  • I see, but it's really handy if piecewise_construct can be get rid of for std::multimap
    – Lei Yu
    37 mins ago













up vote
6
down vote

favorite









up vote
6
down vote

favorite











c++17 introduces try_emplace method for std::map, so now I can write code like below



struct Test

{

    Test(int i, int j){}

};

std::map<int, Test> tmap;

tmap.try_emplace(10, 10, 10);


but there is no try_emplace for std::multimap, so piecewise_construct is still needed.



Is there a technical reason for this?






c++ c++17







share|improve this question















c++17 introduces try_emplace method for std::map, so now I can write code like below



struct Test

{

    Test(int i, int j){}

};

std::map<int, Test> tmap;

tmap.try_emplace(10, 10, 10);


but there is no try_emplace for std::multimap, so piecewise_construct is still needed.



Is there a technical reason for this?






c++ c++17




c++ c++17






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 56 mins ago









Shafik Yaghmour

125k23320527




125k23320527










asked 5 hours ago









Lei Yu

484




484








  • 1




    std::multimap does not need try_emplace as it always inserts, so emplace is enough.
    – Slava
    4 hours ago










  • I see, but it's really handy if piecewise_construct can be get rid of for std::multimap
    – Lei Yu
    37 mins ago














  • 1




    std::multimap does not need try_emplace as it always inserts, so emplace is enough.
    – Slava
    4 hours ago










  • I see, but it's really handy if piecewise_construct can be get rid of for std::multimap
    – Lei Yu
    37 mins ago








1




1




std::multimap does not need try_emplace as it always inserts, so emplace is enough.
– Slava
4 hours ago




std::multimap does not need try_emplace as it always inserts, so emplace is enough.
– Slava
4 hours ago












I see, but it's really handy if piecewise_construct can be get rid of for std::multimap
– Lei Yu
37 mins ago




I see, but it's really handy if piecewise_construct can be get rid of for std::multimap
– Lei Yu
37 mins ago












2 Answers
2






active

oldest

votes

















up vote
4
down vote













As pointed out in the comments it is not necessary. The rational for adding it to map was all the error prone code needed to deal with the case that key already exits, see the proposal n4279 (emphasis mine):




The existing interface of unique-keyed map containers (std::map,
std::unordered_map) is slightly underspecified, which makes certain
container mutations more complicated to write and error-prone than
necessary. This paper describes new member function templates to
fill this gap.



The justification and rationale for the new interface are given in
N3873. The initial reaction to N3873 in Issaquah was that the existing
map interfaces should be fixed rather than adding new interfaces. We
explored this idea in N4006 in Rapperswil and decided that the
original proposal was preferable (with some name changes). This paper
only summarises the proposed extension without repeating the original
discussion. We only restate the motivating code snippet here for
motivation:



std::map<std::string, std::unique_ptr<Foo>> m;

m["foo"] = nullptr;



auto ptr = std::make_unique_ptr<Foo>;

auto res = m.emplace("foo", std::move(ptr));



assert(ptr);    // ??? (may or may not fire)






share|improve this answer

















  • 1




    thanks for the explanation, but it's kind of against intuition that ptr would still be valid after std::move is called on it.
    – Lei Yu
    40 mins ago










  • @LeiYu I believe the answer here explains the issues with emplace and unique_ptr and why this is the case.
    – Shafik Yaghmour
    10 mins ago


















up vote
3
down vote














is there a technical reason for this?




Yes. The purpose of try_emplace() is to not do anything if the key already exists in the map. But for std::{unordered_,}multi{map,set}, you can have multiple values for each key. That is, indeed, the point of these containers: to have multiple values for a given key.



As a result, try_emplace() cannot fail for these containers - so it would be confusing and pointless to provide such a function.






share|improve this answer





















    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%2f53772218%2fwhy-try-emplace-is-not-implemented-for-stdmultimap%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
    4
    down vote













    As pointed out in the comments it is not necessary. The rational for adding it to map was all the error prone code needed to deal with the case that key already exits, see the proposal n4279 (emphasis mine):




    The existing interface of unique-keyed map containers (std::map,
    std::unordered_map) is slightly underspecified, which makes certain
    container mutations more complicated to write and error-prone than
    necessary    . This paper describes new member function templates to
    fill this gap.



    The justification and rationale for the new interface are given in
    N3873. The initial reaction to N3873 in Issaquah was that the existing
    map interfaces should be fixed rather than adding new interfaces. We
    explored this idea in N4006 in Rapperswil and decided that the
    original proposal was preferable (with some name changes). This paper
    only summarises the proposed extension without repeating the original
    discussion. We only restate the motivating code snippet here for
    motivation:



    std::map<std::string, std::unique_ptr<Foo>> m;
    
m["foo"] = nullptr;
    

    
auto ptr = std::make_unique_ptr<Foo>;
    
auto res = m.emplace("foo", std::move(ptr));
    

    
assert(ptr);    // ??? (may or may not fire)






    share|improve this answer

















    • 1




      thanks for the explanation, but it's kind of against intuition that ptr would still be valid after std::move is called on it.
      – Lei Yu
      40 mins ago










    • @LeiYu I believe the answer here explains the issues with emplace and unique_ptr and why this is the case.
      – Shafik Yaghmour
      10 mins ago















    up vote
    4
    down vote













    As pointed out in the comments it is not necessary. The rational for adding it to map was all the error prone code needed to deal with the case that key already exits, see the proposal n4279 (emphasis mine):




    The existing interface of unique-keyed map containers (std::map,
    std::unordered_map) is slightly underspecified, which makes certain
    container mutations more complicated to write and error-prone than
    necessary    . This paper describes new member function templates to
    fill this gap.



    The justification and rationale for the new interface are given in
    N3873. The initial reaction to N3873 in Issaquah was that the existing
    map interfaces should be fixed rather than adding new interfaces. We
    explored this idea in N4006 in Rapperswil and decided that the
    original proposal was preferable (with some name changes). This paper
    only summarises the proposed extension without repeating the original
    discussion. We only restate the motivating code snippet here for
    motivation:



    std::map<std::string, std::unique_ptr<Foo>> m;
    
m["foo"] = nullptr;
    

    
auto ptr = std::make_unique_ptr<Foo>;
    
auto res = m.emplace("foo", std::move(ptr));
    

    
assert(ptr);    // ??? (may or may not fire)






    share|improve this answer

















    • 1




      thanks for the explanation, but it's kind of against intuition that ptr would still be valid after std::move is called on it.
      – Lei Yu
      40 mins ago










    • @LeiYu I believe the answer here explains the issues with emplace and unique_ptr and why this is the case.
      – Shafik Yaghmour
      10 mins ago













    up vote
    4
    down vote










    up vote
    4
    down vote









    As pointed out in the comments it is not necessary. The rational for adding it to map was all the error prone code needed to deal with the case that key already exits, see the proposal n4279 (emphasis mine):




    The existing interface of unique-keyed map containers (std::map,
    std::unordered_map) is slightly underspecified, which makes certain
    container mutations more complicated to write and error-prone than
    necessary    . This paper describes new member function templates to
    fill this gap.



    The justification and rationale for the new interface are given in
    N3873. The initial reaction to N3873 in Issaquah was that the existing
    map interfaces should be fixed rather than adding new interfaces. We
    explored this idea in N4006 in Rapperswil and decided that the
    original proposal was preferable (with some name changes). This paper
    only summarises the proposed extension without repeating the original
    discussion. We only restate the motivating code snippet here for
    motivation:



    std::map<std::string, std::unique_ptr<Foo>> m;
    
m["foo"] = nullptr;
    

    
auto ptr = std::make_unique_ptr<Foo>;
    
auto res = m.emplace("foo", std::move(ptr));
    

    
assert(ptr);    // ??? (may or may not fire)






    share|improve this answer












    As pointed out in the comments it is not necessary. The rational for adding it to map was all the error prone code needed to deal with the case that key already exits, see the proposal n4279 (emphasis mine):




    The existing interface of unique-keyed map containers (std::map,
    std::unordered_map) is slightly underspecified, which makes certain
    container mutations more complicated to write and error-prone than
    necessary    . This paper describes new member function templates to
    fill this gap.



    The justification and rationale for the new interface are given in
    N3873. The initial reaction to N3873 in Issaquah was that the existing
    map interfaces should be fixed rather than adding new interfaces. We
    explored this idea in N4006 in Rapperswil and decided that the
    original proposal was preferable (with some name changes). This paper
    only summarises the proposed extension without repeating the original
    discussion. We only restate the motivating code snippet here for
    motivation:



    std::map<std::string, std::unique_ptr<Foo>> m;
    
m["foo"] = nullptr;
    

    
auto ptr = std::make_unique_ptr<Foo>;
    
auto res = m.emplace("foo", std::move(ptr));
    

    
assert(ptr);    // ??? (may or may not fire)







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 4 hours ago









    Shafik Yaghmour

    125k23320527




    125k23320527








    • 1




      thanks for the explanation, but it's kind of against intuition that ptr would still be valid after std::move is called on it.
      – Lei Yu
      40 mins ago










    • @LeiYu I believe the answer here explains the issues with emplace and unique_ptr and why this is the case.
      – Shafik Yaghmour
      10 mins ago














    • 1




      thanks for the explanation, but it's kind of against intuition that ptr would still be valid after std::move is called on it.
      – Lei Yu
      40 mins ago










    • @LeiYu I believe the answer here explains the issues with emplace and unique_ptr and why this is the case.
      – Shafik Yaghmour
      10 mins ago








    1




    1




    thanks for the explanation, but it's kind of against intuition that ptr would still be valid after std::move is called on it.
    – Lei Yu
    40 mins ago




    thanks for the explanation, but it's kind of against intuition that ptr would still be valid after std::move is called on it.
    – Lei Yu
    40 mins ago












    @LeiYu I believe the answer here explains the issues with emplace and unique_ptr and why this is the case.
    – Shafik Yaghmour
    10 mins ago




    @LeiYu I believe the answer here explains the issues with emplace and unique_ptr and why this is the case.
    – Shafik Yaghmour
    10 mins ago












    up vote
    3
    down vote














    is there a technical reason for this?




    Yes. The purpose of try_emplace() is to not do anything if the key already exists in the map. But for std::{unordered_,}multi{map,set}, you can have multiple values for each key. That is, indeed, the point of these containers: to have multiple values for a given key.



    As a result, try_emplace() cannot fail for these containers - so it would be confusing and pointless to provide such a function.






    share|improve this answer

























      up vote
      3
      down vote














      is there a technical reason for this?




      Yes. The purpose of try_emplace() is to not do anything if the key already exists in the map. But for std::{unordered_,}multi{map,set}, you can have multiple values for each key. That is, indeed, the point of these containers: to have multiple values for a given key.



      As a result, try_emplace() cannot fail for these containers - so it would be confusing and pointless to provide such a function.






      share|improve this answer























        up vote
        3
        down vote










        up vote
        3
        down vote










        is there a technical reason for this?




        Yes. The purpose of try_emplace() is to not do anything if the key already exists in the map. But for std::{unordered_,}multi{map,set}, you can have multiple values for each key. That is, indeed, the point of these containers: to have multiple values for a given key.



        As a result, try_emplace() cannot fail for these containers - so it would be confusing and pointless to provide such a function.






        share|improve this answer













        is there a technical reason for this?




        Yes. The purpose of try_emplace() is to not do anything if the key already exists in the map. But for std::{unordered_,}multi{map,set}, you can have multiple values for each key. That is, indeed, the point of these containers: to have multiple values for a given key.



        As a result, try_emplace() cannot fail for these containers - so it would be confusing and pointless to provide such a function.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 4 hours ago









        Barry

        175k18299554




        175k18299554






























            draft saved

            draft discarded




















































            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.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


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




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53772218%2fwhy-try-emplace-is-not-implemented-for-stdmultimap%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

            404 Error Contact Form 7 ajax form submitting

            Image
            0 The contact form does not work, and affects loading after one try. The chrome console shows the error message: POST http://example.com/wp-json/contact-form-7/v1/contact-forms/50/feedback 404 (Not Found) send @ jquery.js?ver=1.12.4:4 ajax @ jquery.js?ver=1.12.4:4 wpcf7.submit @ scripts.js?ver=5.0.3:346 (anonymous) @ scripts.js?ver=5.0.3:53 dispatch @ jquery.js?ver=1.12.4:3 r.handle @ jquery.js?ver=1.12.4:3 How to solve this issue? thanks in advance javascript wordpress contact-form-7 share | improve this question edited Jul 17 '18 at 5:39 Kiran Shahi 4,745 3 16 43
            Read more

            How to know if a Active Directory user can login interactively

            Image
            1 I would like to know if and how is it possible to know if a AD user can login interactively (on a server) in a domain. I need to know if I can find it out using a LDAP search. Thanks. windows active-directory login user-permissions user-profile share | improve this question edited 1 hour ago yagmoth555 ♦ 11.6k 3 17 42 asked 1 hour ago Luigi Luigi 6 1 New contributor
            Read more

            TypeError: fit_transform() missing 1 required positional argument: 'X'

            Image
            0 I am trying to do Feature Scaling in a dataset, but I get an error and have no idea how to proceed: > Traceback (most recent call last): > > File "<ipython-input-10-71bea414b4d0>", line 22, in <module> > x_train = sc_X.fit_transform(x_train) > > TypeError: fit_transform() missing 1 required positional argument: 'X' and here is my code: import pandas as pd # Importing the dataset dataset = pd.read_csv('Data.csv') X = dataset.iloc[:, :-1].values y = dataset.iloc[:, 3].values # Taking care of missing data from sklearn.preprocessing import Imputer imputer = Imputer(missing_values="NaN", strategy="mean", axis=0) imputer = Imputer.fit(imputer,X[:,1:3]) X[:, 1:3] = Imputer.transform(imputer,X[
            Read more