This is the mail archive of the 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]

Re: Value type of map need not be default copyable


On 08/09/2012 09:14 AM, Marc Glisse wrote:
On Wed, 8 Aug 2012, FranÃois Dumont wrote:

On 08/08/2012 03:39 PM, Paolo Carlini wrote:
On 08/08/2012 03:15 PM, FranÃois Dumont wrote:
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.


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

I was still hoping that for something as simple as mapped_type() we wouldn't need the full <tuple> machinery, and I encourage everybody to have another look (while making sure anything we figure out adapts smoothly an consistently to std::map), then in a few days we'll take a final decision. We'll still have chances to further improve the code in time for 4.8.0.

+         __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.
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]