From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-08-13 18:02:09
On Tue, Aug 13, 2019 at 7:18 AM Phil Endecott via Boost <
> Zach Laine wrote:
> > On Mon, Aug 12, 2019 at 8:38 AM Phil Endecott via Boost <
> > boost_at_[hidden]> wrote:
> >> Hans Dembinski wrote:
> >> > compare vs. distance_to
> >> This reminds me of an issue that I've found with the existing
> >> iterator_facade: sometimes I can magnitude-compare the iterators,
> >> but not report a distance.
> >> For example, a simple filter iterator can quickly tell whether A is
> >> before or after B by comparing the underlying iterators, but it cannot
> >> find the distance without applying its filter predicate to all the
> >> intermediate elements.
> >> Currently, operator< etc. in the facade are implemented by calling
> >> the user's distance_to which is inefficient in this case. Your change
> >> of name to compare made me wonder if it is now expected only to return
> >> -1/0/+1, but that doesn't seem to be the case.
> > I think this is out of scope for the library, simply because the library
> > for making models of the C++20 iterator concepts. An iterator like you
> > describe is not one of those -- an iterator that is not random access and
> > yet has operator<() may be useful to you in some situations, but it is
> > useful for communicating capabilities to standard algorithms.
> I disagree. If I try to use std::sort() or std::map<> with these
> they don't (IIUC) check the iterator category, but rather they just need
> operator< (or std::less?) to be defined.
std::map is a read herring. It does not need operator< on iterators, only
As for std::sort, the existence of operator< on iterators is not enough to
make this work. For instance, sort is allowed to use offsets and
operator on your iterator, and yet there's no such thing.
These concepts exist for a reason, and I'm not interested in subverting
> Yes I can add them myself, but adding all of <, <=, >, >= is,
> tedious and a little error-prone - exactly the sort of boilerplate code
> iterator_facade is trying to help eliminate.
Right, but in the cases you mention you only need operator<, right?
Moreover, all the requirements on each concept are actually checked in the
std::ranges algorithms. Only having operator< does not help you use
algorithms that require a random_access_iterator does not work if the
algorithm only uses operator<; the concept-checking machinery will still
error out if you don't meet the full concept.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk