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-iterato... Sent from the Boost - Dev mailing list archive at Nabble.com.