Optimize hashtable allocator

Jonathan Wakely jwakely.gcc@gmail.com
Wed Oct 31 22:26:00 GMT 2012


On 31 October 2012 22:14, François Dumont wrote:
> On 10/30/2012 10:26 PM, Jonathan Wakely wrote:
>
>     Are you sure all GDB 7.x should work ? I have gdb 7.1 and when running
> pretty printers tests I have:
>
> Spawning: gdb -nw -nx -quiet -batch -ex "python print
> gdb.lookup_global_symbol"
> ESC[?1034hTraceback (most recent call last):
>   File "<string>", line 1, in <module>
> AttributeError: 'module' object has no attribute 'lookup_global_symbol'
> Error while executing Python code.
> UNSUPPORTED: prettyprinters.exp

Ah sorry, it seems the tests need GDB 7.3

Don't worry about changing the printers then, I can do that later.


>>>   By the way, there is suspect
>>> code in it. It tries to deal with std and std::tr1 unordered containers
>>> through the same python code but it won't work anymore for iterators.
>>> They
>>> are different in std and tr1 modes so there are adaptations missing if we
>>> still want to support both versions.
>>
>> Yes we want to support both.
>>
>> Can the difference between the iterators be handled easily the same
>> way I changed the printers to use _M_h when necessary, or should be
>> just have separate StdHashtableIterator and Tr1HashtableIterator
>> printers?
>
>
> Yes, I think the same code could deal both type of iterators.

Excellent.

>>
>>
>>> 2012-09-29  François Dumont  <fdumont@gcc.gnu.org>
>>
>> 2012-10  :)
>>
>> +
>> +      template<typename _Alloc>
>> +       _Before_begin(_Alloc __a)
>> +         : _NodeAlloc(__a)
>> +       { }
>>
>> Can this use a "universal reference" (to use Scott Meyers's term) to
>> avoid a copy?
>>
>>        template<typename _Alloc>
>>         _Before_begin(_Alloc&& __a)
>>           : _NodeAlloc(std::forward<_Alloc>(__a))
>>         { }
>>
>> There's no need to use Doxygen for _Before_begin, it's not for end users.
>>
>     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.

That patch is OK for trunk, thanks!



More information about the Libstdc++ mailing list