------- Comment #13 from redi at gcc dot gnu dot org 2010-04-19 15:26 ------- (In reply to comment #10) > However, what would make_pair have deduced its T1 and T2 to be in this > example? > My impression was "make_pair(x,y)" would have deduced T1=uint32_t and > T2=uint32_t. Therefore, "make_pair<uint32_t,uint32_t>(x,y)" should be > synonymous.
No, it would have deduced them as uint32_t& so make_pair<uint32_t&,uint32_t&> is synonymous. Otherwise it tries to bind uint32_t&& to an lvalue, which is not allowed. > The part that is confusing is if I do a diff on bits/stl_pair.h between > GCC4.4.2 and GCC4.5.0, the constructor has not changed. Yet it compiles with > -std=c++0x on GCC4.4.2 but errors with -std=c++0x on GCC4.5.0 (which is why I > opened it up as a bug report to c++ initially rather than libstdc++). GCC 4.4 does not implement the updated rvalue reference semantics that prevent lvalues binding to rvalues. (In reply to comment #12) > (In reply to comment #9) > > Also, make_pair's reason for existing is to deduce template arguments. If > > you > > don't want argument deduction why use make_pair? > > True. I don't know why one would want to do this either, but several people > happened to do so about half a dozen times in our 500,000 lines of code. Well it's about time someone put a stop to it ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
