Boost logo

Geometry :

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:

   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:

   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.



Geometry list run by mateusz at