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. 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 them.
Yes I can add them myself, but adding all of <, <=, >, >= is, pre-spaceship, tedious and a little error-prone - exactly the sort of boilerplate code that 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. Zach