Boost logo

Boost :

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-08-12 16:04:07


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. 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk