Am Do., 1. Aug. 2019 um 11:57 Uhr schrieb Jonathan Wakely <jwak...@redhat.com>: > > More comments inline below ... [..] > > >François > > > >On 6/19/19 7:32 PM, François Dumont wrote: > >>I wanted to implement Debug overloads for those already existing > >>overloads but then realized that those algos could be generalized. > >>This way we will benefit from the memmove replacement when operating > >>with C array or std::array or std::vector iterators. > >> > >>I might do the same for lexicographical_compare one day. > >> > >>The ChangeLog below is quite huge so I attached it. I wonder if I > >>could use deque::iterator and deque::const_iterator in place of the > >>_Deque_iterator<> to reduce it ? > >> > >>Tested under Linux x86_64 normal and debug modes, ok to commit ? > >> > >>François > >> > > > > >diff --git a/libstdc++-v3/include/bits/deque.tcc > >b/libstdc++-v3/include/bits/deque.tcc > >index 3f77b4f079c..9db869fb666 100644 > >--- a/libstdc++-v3/include/bits/deque.tcc > >+++ b/libstdc++-v3/include/bits/deque.tcc > >@@ -967,155 +967,507 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER > > this->_M_impl._M_finish._M_set_node(__new_nstart + __old_num_nodes - > > 1); > > } > > [..] > > And anyway, isn't _Deque_iterator<T, T&, T*>::_Self just the same type as > _Deque_iterator<T, T&, T*> ? It should be something like: > > typedef typename _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&, _Tp*> _Iter; > > >+ template<typename _II, typename _Tp> > >+ typename enable_if< > >+ is_same<typename std::iterator_traits<_II>::iterator_category, > >+ std::random_access_iterator_tag>::value, > > Use is_base_of<random_access_iterator_tag, ...::iterator_category> so > it works for types derived from random_access_iterator_tag too.
Interesting. Traditional type tag dispatching approaches (as function parameters) do have more in a manner that would be equivalent to an implicit conversion (Being used as "by-value-parameters"), so I'm wondering whether this should not instead refer to is_convertible? I also found examples where this trait is currently used in <stl_algo.h> such as static_assert( __or_<is_convertible<__pop_cat, forward_iterator_tag>, is_convertible<__samp_cat, random_access_iterator_tag>>::value, "output range must use a RandomAccessIterator when input range" " does not meet the ForwardIterator requirements"); Should possibly this trait be preferred? - Daniel