On 3/6/20 11:12 AM, Jonathan Wakely wrote:
On 06/03/20 10:09 +0000, Jonathan Wakely wrote:
On 06/03/20 07:06 +0100, François Dumont wrote:
I started to work on ranges::equal to find out if what I am trying
to do is totally silly.
With this patch ranges::equal is in pare with std::equal
specializations that is to say that it correctly deals with Debug
mode or std::deque iterators.
Once below patch is in:
https://gcc.gnu.org/ml/libstdc++/2019-12/msg00032.html
We will even be able to call std::__equal_aux1 directly using
__niter_base to get rid of the Debug safe iterator layer. And even
in this case get rid of the branch __use_memcmp and leave it to
__equal_aux1.
I mainly fear the usage of std::iterator_traits in __equal_aux1 to
be a problem. Is it in this context of sized_sentinel ?
I don't understand the question. No sentinel of type _Sent1 or _Sent2
gets passed to __equal_aux1 with your patch, you only pass iterators.
I just thought that std::iterator_traits was becoming somehow obsolete
is the more recent Standard and that it was the reason for not using
existing std algos.
But I think the patch is wrong:
+ return !std::__memcmp(__first1, __first2, __d1);
+ else
+ return std::__equal_aux(__first1, __first1 + __d1,
__first2);
This last line will only compile if _Iter1 is random access, but all
we know at this point is that _Sent1 is a sized sentinel for _Iter1.
That doesn't mean it's necessarily random access.
Please try the example at https://wg21.link/counted.iterator#2 which
uses counted_iterator<list<string>::iterator> and default_sentinel.
The sized_sentinel_for concept is satisfied, but you can't do first1+d1.
Thanks for this example, now I know what has to be supported. I'll see
if I can find a solution before you do.
François
