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).