Boost logo

Boost :

Subject: Re: [boost] sentinels vs iterators
From: pfultz2 (pfultz2_at_[hidden])
Date: 2014-08-21 17:34:59

> There is also possible to perform iterative queries implemented as
> iterators. To get the iterator one calls a member function the same way
> as the one above:
> rtree.qbegin(bgi::intersects(box1) && !bgi::within(box2));
> this means that the type of an iterator depends on the type of the
> query. But the container in general should also define the type of an
> iterator. To keep the story short, I was forced to implement type-erased
> iterators. This also allowed me to internally use different iterators
> for begin and end. Otherwise it would be required to pass pass the query
> also to qend() method, since its type would also depend on the query's
> type. So the user may just write:
> rtree.qend();
> to get the end iterator. Technically the end iterator of course could
> have the same type and also store the query however then iterative
> queries are slower because the iterator is bigger. And as you can
> imagine type-erased iterators are also slower than "regular" ones.

There is no need to use type-erased iterators here. Instead it should return

    rtree.qrange(bgi::intersects(box1) && !bgi::within(box2));

Then the range that is returned will know the query type that is needed for
the `.begin()` and `.end()` member functions. Plus, returning a range is
helpful if the user wants to use it in a range-for loop or with Boost.Range.

Also, I'm not sure using different iterators types in this case has a boost
performance, since the end iterator is pointing to a 'valid' place in the
sequence, unlike an end iterator for a null-terminated string which is just
placeholder for the end.


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at