Geometry Boost List: Re: [geometry] [index] rtree iterative queries

Subject: Re: [geometry] [index] rtree iterative queries
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-09-15 20:25:46

Hi Bruno,

Bruno Lalande wrote:
> Hi Adam,
>
> Sorry for the late answer... Thanks for that, I'm fine with this 
> solution. If you still have problems or concerns about performance of 
> type erasure maybe you could dig into how Boost.Function implements 
> that without virtual function calls? Efficiency figures are presented 
> here: 
> http://www.boost.org/doc/libs/1_54_0/doc/html/function/misc.html#idp60516496. 
> You could even have the predicates implemented in terms of 
> Boost.Function which would de-facto make them type-erased instead of 
> the whole iterator... Just a general thought though, if you happy with 
> your implementation just keep it like this.
>

Thanks for the suggestions, I haven't thought about Boost.Function. I've 
just tested this approach. Maybe there is some more optimal way of doing 
it (I'm binding each method instead of making it virtual) but those 
iterators are slightly slower. I think it's because somehow the function 
must be called, somehow the dispatch between the types must be done and 
the way the compiler does it is probably the most optimal. Moreover 
including Boost.Function would be additional dependency so for now I'll 
leave it as it is. If you like to check it out for yourself, various 
implementations may be enabled in 
geometry/index/detail/rtree/query_iterators.hpp file.

As for the type-erased Predicates I thought about it too. Unfortunately 
not only Predicates would have to be type-erased. The internals of the 
iterator are different for spatial and knn queries so they should also 
be type-erased, and those internals are the major part of the iterator.

But the support for type-erased predicates could be useful for the same 
reason why the type-erased iterator is. E.g. someone could store 
Predicates and later pass them to the query() function. Though I'm not 
sure if this functionality is needed and makes sense because the 
predicates are still defined in compile time. What could really be 
useful are run-time predicates which could be connected together in 
run-time and then passed to the query but this is probably more distant 
future.

Regards,
Adam