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