Rb_tree constructor optimization

François Dumont frs.dumont@gmail.com
Thu Oct 19 05:39:00 GMT 2017


Hi

     Any feedback regarding this patch ?

Thanks,
François

On 14/09/2017 22:04, François Dumont wrote:
> I realized there was no test on the noexcept qualification of the move 
> constructor with allocator.
>
> I added some and found out that patch was missing a noexcept 
> qualification at _Rb_tree level.
>
> Here is the updated patch fully tested, ok to commit ?
>
> François
>
>
> On 13/09/2017 21:57, François Dumont wrote:
>> On 08/09/2017 17:50, Jonathan Wakely wrote:
>>>
>>> Since we know __a == __x.get_allocator() we could just do:
>>>
>>>      _Rb_tree(_Rb_tree&& __x, _Node_allocator&&, true_type)
>>> noexcept(is_nothrow_move_constructible<_Rb_tree_impl<_Compare>>::value)
>>>      : _M_impl(std::move(__x._M_impl))
>>>      { }
>>>
>>> This means we don't need the new constructor.
>>
>>     You want to consider that a always equal allocator is stateless 
>> and so that the provided allocator rvalue reference do not need to be 
>> moved. IMHO you can have allocator with state that do not participate 
>> in comparison like some monitoring info.
>>
>>     I'm not confortable with that and prefer to keep current behavior 
>> so I propose this new patch considering all your other remarks.
>>
>>     I change noexcept qualification on [multi]map/set constructors to 
>> just rely on _Rep_type constructor noexcept qualification to not 
>> duplicate it.
>>
>> François
>>
>>
>
>
>

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


More information about the Libstdc++ mailing list