Re: Value type of map need not be default copyable

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,

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

Thanks!
Paolo.