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. Also, it's easy for you to bolt this on yourself if it's useful to you.
The other thing that I've found tedious to do with the current iterator_facade is implementing both iterator and const_iterator. The pattern I tend to use is:
template <bool is_const> class iterator_base: public boost::iterator_facade< ......... > ......
using iterator = iterator_base<false>; using const_iterator = iterator_base<true>;
I don't know if there is anything that iterator_facade could do to make this easier.
I've struggled with this too. I have not found a good way to deal with this. I think the best we can do is something like what you show above. One day reflection and/or "metaclass"-style source generation may be the way to do this. Zach