Re: [boost] sentinels vs iterators

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
a
range:

    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
in
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
a
placeholder for the end.

Paul

--
View this message in context: http://boost.2283326.n4.nabble.com/NTCTS-Iterator-was-Interest-in-is-iterator-type-trait-tp4666650p4666741.html
Sent from the Boost - Dev mailing list archive at Nabble.com.