On Tue, Aug 13, 2019 at 2:01 PM Zach Laine via Boost <boost@lists.boost.org> wrote:
On Tue, Aug 13, 2019 at 7:18 AM Phil Endecott via Boost < boost@lists.boost.org> wrote:
Zach Laine wrote:
On Mon, Aug 12, 2019 at 8:38 AM Phil Endecott via Boost < boost@lists.boost.org> 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