Re: [boost] new library (space partitioning)

Subject: Re: [boost] new library (space partitioning)
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2010-08-07 10:29:41

Le 29/07/2010 20:07, Simonson, Lucanus J wrote:
> Your interface seems a little off to me, not what I was expecting.

I have to agree, and add more to that.

What a spatial index does is fairly simple (to the user). Its interface 
should be the same as that of std::multiset, but instead of using 
operator<, it should use intersection (which, like std::multiset, should 
have a default but be changeable to an arbitrary function object).
You're going to want to change std::multiset<T>::find slightly to allow 
arbitrary types, not just T (often considered an arbitrary limitation 
and defect by people), and to return a range instead of an iterator; and 
you might want to lazily evaluate that range as well, hence providing 
the incremental search you put on your to-do list.

The default intersection function would obviously be a generic one from 
Geometry.
I'm not sure Geometry has such a generic intersection function; but if 
it doesn't, that where it needs to be.

Volume queries, ray queries etc. don't need anything special. They 
should work with the generic intersection function just like the rest, 
no need to special case anything.

There is no need to introduce any new point/object concept, nor new nD 
containers. The spatial index should assume the very least information 
it needs in order to be truly generic.

All the implementation details you might need should be in Geometry, and 
the default intersection function should be from Geometry as well (if 
they're not, that's where they should be anyway), so I don't see why you 
would want to make it a separate library, except out of craziness.

Dynamic typing should not be the responsability of the index, so it 
should work with objects of type T, not pointers, and let the user deal 
with polymorphism, if he needs it, by instantiating the index with smart 
pointers or type erasure types.
Memory allocation is purely dealt with by the allocator, so seeing "use 
of pool allocators" in the to-do list worries me.

I would also like to see an intrusive version of the index, that doesn't 
do any memory allocation. The non-intrusive version can be built on top 
of the intrusive one, but the opposite isn't possible.

So my opinion is that the whole design is done utterly wrong at the moment.
I personally won't consider using it or promoting unless it is exactly 
as I described (intrusive support is optional).