This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, 8 Aug 2012, FranÃois Dumont wrote:When it does, and the corresponding PR will be *ready* we'll reconsider the issue. After all the *months and months and months* spent by the LWG adding and removing members from pair and tweaking everything wrt the containers and issues *still* popping up (like that with the defaulted copy constructor vs insert constraining), and with the support for scoped allocators still missing from our implementation, we are not adding members to std::pair such easily. Sorry, but personally I'm not available now to further discuss this specific point.
On 08/08/2012 03:39 PM, Paolo Carlini wrote:On 08/08/2012 03:15 PM, FranÃois Dumont wrote:Then I can only imagine the attached patch which require to include tuple when including unordered_map or unordered_set. The std::pair(piecewise_construct_t, tuple<>, tuple<>) is the only constructor that allow to build a pair using the default constructor for the second member.I have also introduce a special std::pair constructor for container usage so that we do not have to include the whole tuple stuff just for associative container implementations.To be clear: sorry, this is not an option.
Paolo.
I agree that the extra constructor would be convenient (I probably would have gone with pair(T&&,__default_construct_t), the symmetric version, and enough extra constructors to resolve all ambiguities). Maybe LWG would consider doing something.
Are we already doing that elsewhere? I think we should aim for something simple first, then carefully evaluate if the additional complexity is worth the cost and in case deploy the superior solution consistently everywhere it may apply.+ __p = __h->_M_allocate_node(std::piecewise_construct, + std::make_tuple(__k), + std::make_tuple());
Don't you want cref(__k)? It might save a move at some point.
Thanks! Paolo.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |