Value type of map need not be default copyable
Paolo Carlini
paolo.carlini@oracle.com
Thu Aug 9 08:35:00 GMT 2012
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.
More information about the Gcc-patches
mailing list