Geometry Boost List: Re: [geometry] Rtree interface and translator

Subject: Re: [geometry] Rtree interface and translator
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-02-26 17:45:56

Bruno Lalande wrote:
> Hi Adam,
>
> I'm personally all for option 2, as it is something I had proposed at
> some point. It feels much more natural to me, and more aligned with our
> usual traits-based approach. I understand it may prevent users from
> specifying different behaviors (i.e. different translators) for the same
> type, but I consider that an edge case and there are workarounds.
>

Implementing the spatial index we should be as close to the STD, 
Boost.Geometry and other Boost libraries as possible (in this order). 
Now in the c++11 there are unordered_XXX containers (known from Boost) 
which interface is closer to ours spatial_index than set's/map's:

template<
   class Key,
   class Hash = std::hash<Key>,
   class KeyEqual = std::equal_to<Key>,
   class Allocator = std::allocator<Key>
 > class unordered_set;

Replacing the translator by this interface would solve a few problems:
- rtree would have the interface closer to the std,
- it would be more intuitive (everybody has problems with the 
understanding of the translator)
- there would be no problem with the name or the concept of the 
"translator" which performs 2 operations (retrieving the indexable and 
checking equality)
- there would be possible to implement only one required operation

In our case it would be something like this:

template<
   class Value,
   class Parameters,
   class Indexable = index::indexable<Value>,
   class Equal = std::equal_to<Value>,
   class Allocator = std::allocator<Value>
 > class rtree;

Btw, with the currently used Translator as well as with this interface 
it is possible to specialize the translator/indexable/equal_to for some 
Value type and if only the specialization has default ctor it musn't be 
passed to the rtree/container.

Thoughts?

Regards,
Adam