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