Re: Interest in updated, standalone iterator_facade library?

From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2019-08-18 04:43:10

On Tue, Aug 13, 2019 at 2:01 PM Zach Laine via Boost
<boost_at_[hidden]> wrote:
>
> On Tue, Aug 13, 2019 at 7:18 AM Phil Endecott via Boost <
> boost_at_[hidden]> wrote:
>
> > 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
> > is
> > > 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
> > not
> > > useful for communicating capabilities to standard algorithms.
> >
> > I disagree.  If I try to use std::sort() or std::map<> with these
> > iterators,
> > 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
> on keys.
>

I assume they want to use an iterator (from some container) as a key in a map?

Tony