[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

Jonathan Wakely jwakely.gcc@gmail.com
Sun Nov 25 20:17:00 GMT 2012


On 25 November 2012 17:00, François Dumont <frs.dumont@gmail.com> wrote:
> On 11/23/2012 11:22 PM, Jonathan Wakely wrote:
>>
>> On 23 November 2012 21:59, François Dumont wrote:
>>>
>>> - To create a node I need to request the allocator twice, once for the
>>> node
>>> and an other time for the stored value. This is quite unusual so I don't
>>> know if it is a real problem
>>
>> That's normal for node-based containers.
>>
>> The correct behaviour (see 23.2.1  [container.requirements.general]
>> p3) is to use one allocator type to allocate memory for a node, but
>> *not* use that type to construct the node (instead use placement new),
>> then use a different allocator type to construct the element in the
>> node.  See _M_create_node in <bits/forward_list.h> for more details.
>>
>     I indeed considered your recent modification of forward_list but in my
> patch it is different. I not only build the value with its allocator
> construct method but I also allocate it separately because the node contains
> a pointer to the value and not the value directly.

My point is the code in that patch directly violates the clear wording
in [container.requirements.general] p3:

"For the components affected by this subclause that declare an
allocator_type, objects stored in these
components shall be constructed using the
allocator_traits<allocator_type>::construct function and
destroyed using the allocator_traits<allocator_type>::destroy function
(20.6.8.2). These functions
are called only for the container’s element type, not for internal
types used by the container."

Your patch called construct() for the "internal types used by the
container" i.e. the node types. That's wrong.  All that code will need
to change to use allocator_traits anyway, but if you're making changes
now you should try to follow the requirements in the standard and not
add new code doing the wrong thing.



More information about the Libstdc++ mailing list