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
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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk