Value type of map need not be default copyable

François Dumont frs.dumont@gmail.com
Sat Aug 11 13:29:00 GMT 2012


     Here is an other attempt. I took the time to refactor the hashtable 
implementation. I prefer to rename _M_insert_node into 
_M_insert_unique_node and use it also into _M_emplace implementation. I 
introduce _M_insert_multi_node that is used in _M_insert and _M_emplace 
when keys are not unique.

     Your remark on using std::move rather than std::forward Marc made 
sens but didn't work. I don't understand why but the new test is showing 
that std::forward works. If anyone can explain why std::move doesn't 
work I am interested.

     For your question regarding how to include headers I just follow 
current method. Normally it is done so to make headers more reusable but 
in this case I agree that hashtable_policy.h can't be included without 
<tuple> before. Should I put <tuple> include into hashtable_policy.h ? 
Adding a declaration of std::tuple in hashtable_policy.h could make this 
header less dependent on <tuple>, should I do so ?

2012-08-09  François Dumont  <fdumont@gcc.gnu.org>
         Ollie Wild  <aaw@google.com>

     * include/bits/hashtable.h
     (_Hashtable<>_M_insert_multi_node(hash_code, node_type*)): New.
     (_Hashtable<>_M_insert(_Args&&, false_type)): Use latter.
     (_Hashtable<>::_M_emplace(false_type, _Args&&...)): Likewise.
     (_Hashtable<>::_M_insert_bucket): Replace by ...
     (_Hashtable<>::_M_insert_unique_node(size_type, hash_code, 
node_type*)):
     ... this, new.
     (_Hashtable<>::_M_insert(_Args&&, true_type)): Use latter.
     (_Hashtable<>::_M_emplace(true_type, _Args&&...)): Likewise.
     * include/bits/hashtable_policy.h (_Map_base<>::operator[]): Use
     latter, emplace the value_type rather than insert.
     * include/std/unordered_map: Include tuple.
     * include/std/unordered_set: Likewise.
     * testsuite/util/testsuite_counter_type.h: New.
     * testsuite/23_containers/unordered_map/operators/2.cc: New.

Tested under linux x86_64, normal and debug mode.

Ok for trunk ?

François

On 08/10/2012 01:26 AM, Paolo Carlini wrote:
> On 08/09/2012 11:22 PM, Marc Glisse wrote:
>> I don't know if std:: is needed, but it looks strange to have it only 
>> on some functions:
>> std::forward_as_tuple(forward<key_type>(__k)),
>>
>> Looking at this line again, you seem to be using std::forward on 
>> something that is not a deduced parameter type. I guess it is 
>> equivalent to std::move in this case, it just confuses me a bit.
> Wanted to point out that yesterday. Please double check std::move.
>
> I realize now that nobody is interested in std::cref, good ;)
>
> Thanks!
> Paolo.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hashtable.patch
Type: text/x-patch
Size: 19925 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20120811/1d43fc63/attachment.bin>


More information about the Libstdc++ mailing list