Deque code cleanup and optimizations

[François Dumont]

Here is the simplified patch. I put back the _M_map checks, we'll see 
later if those can be removed.

 Â Â Â  * include/bits/stl_deque.h
 Â Â Â  (_Deque_iterator<>::__ptr_to): Remove, use std::__ptr_rebind.
 Â Â Â  (_Deque_base(_Deque_base&&, const allocator_type&)): New.
 Â Â Â  (_Deque_base::_Deque_impl_data): New.
 Â Â Â  (_Deque_base::_Deque_impl): Inherit latter.
 Â Â Â  (_Deque_base::_Deque_impl::_M_swap_data): Move...
 Â Â Â  (_Deque_base::_Deque_impl_data::_M_swap_data): ... here.
 Â Â Â  (_Deque_base::_Deque_impl()): Add noexcept qualification.
 Â Â Â  (_Deque_base::_Deque_impl(_Deque_impl&&, _Tp_alloc_type&&)): New.
 Â Â Â  (_Deque_base::_Deque_impl::_M_get_Tp_allocator()): Remove static_cast.
 Â Â Â  (deque<>::deque()): Default.
 Â Â Â  (deque<>::deque(deque&&)): Default.
 Â Â Â  (deque<>::deque(deque&&, const allocator_type&, false_type)): New.
 Â Â Â  (deque<>::deque(deque&&, const allocator_type&, true_type)): New.
 Â Â Â  (deque<>::deque(deque&&, const allocator_type&)): Delegate to latters.
 Â Â Â  (deque<>::deque<_It>(_It, _It, const allocator_type&)): Use
 Â Â Â  _M_range_initialize.
 Â Â Â  (deque<>::assign<_It>(_It, _It)): Use _M_assign_aux.
 Â Â Â  (deque<>::resize(size_type, const value_type&)): Share a single
 Â Â Â  implementation.
 Â Â Â  (deque<>::insert<_It>(const_iterator, _It, _It)): Use
 Â Â Â  _M_range_insert_aux.
 Â Â Â  [__cplusplus >= 201103L](_M_initialize_dispatch): Remove.
 Â Â Â  [__cplusplus >= 201103L](_M_assign_dispatch): Remove.
 Â Â Â  [__cplusplus >= 201103L](_M_insert_dispatch): Remove.
 Â Â Â  * testsuite/23_containers/deque/allocator/default_init.cc: New.

Tested under Linux x86_64.

Ok to commit ?

François

On 5/10/19 3:38 PM, Jonathan Wakely wrote:
> This seems generally OK, but ...
>
> On Fri, 10 May 2019, 05:59 François Dumont wrote:
>>       I remove several _M_map != nullptr checks cause in current
>> implementation it can't be null. I have several patches following this
>> one to support it but in this case we will be using a different code path.
>
> You can't remove those checks. If _M_map can ever be null now or in
> the future, then we need the checks. Otherwise code compiled today
> would break if passed a deque compiled with a future GCC that allows
> the map to be null.
>
> I'm curious how you plan to support it though, I don't think it's
> possible without an ABI break.
>
>>       (_Deque_base::_Deque_impl::_M_move_impl()): Remove _M_impl._M_map
>> check.
> _M_move_impl and the constructor that calls it can be removed
> completely, because https://cplusplus.github.io/LWG/issue2593 means
> that the same allocator can still be used after moving from it. That
> function only exists to handle the case where an allocator changes
> value after being moved from.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: deque.patch
Type: text/x-patch
Size: 15240 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20190517/d035479e/attachment.bin>