Optimize hashtable allocator

[Jonathan Wakely]

On 31 October 2012 22:46, Marc Glisse wrote:
> On Wed, 31 Oct 2012, Jonathan Wakely wrote:
>
>> On 31 October 2012 22:14, François Dumont wrote:
>>>
>>>     Here is the patch I came to. I use the 'universal reference' like you
>>> propose but some tests started to fail because I think gcc called it
>>> instead
>>> of the move constructor.
>>
>>
>> Ah of course.  The defaulted copy/move constructors you added are the
>> right solution for that.
>
>
> Assuming you never copy a non-const lvalue or a const rvalue. The current
> use seems ok, I just wanted to mention that it is rather fragile.

Yes, true.  The code that uses that constructor is entirely under the
implementation's control so it should be avoidable.

If it's ever a problem we could change the constructor to a
non-template then explicitly construct it with the right type:

       _M_bbegin(_Node_allocator_type(__a)),