Am Do., 1. Aug. 2019 um 13:01 Uhr schrieb Jonathan Wakely <jwak...@redhat.com>: > > On 01/08/19 12:36 +0200, Daniel Krügler wrote: > >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? > > Hmm, I don't know why I did it that way in sample. > > The standard requires derivation in a couple of places today, see > [reverse.iterator] bullet 2.1 and [move.iterator] bullet 1.1 which use > DerivedFrom<random_access_iterator_tag> to check whether the base > iterator is random access or not.
If you want to mimic DerivedFrom you also need to include is_convertible in some way, because is_base_of does not care about access. Maybe introduce __is_derived_from? - Daniel
