Mathias Gaunard wrote:
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.
Yes, I wrote earlier that the interface should be redesigned and that I'd like to write the library, not that I have one fully functional. I've decided to show you the code as it is because I knew that you'll have many objections, different people will have different views and because I don't know about your plans and what is needed. I'm gathering information right now.
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.
It depends, how you see these things. You may want spatial index or various spacial indexes in Boost.Geometry. But you may also want multi-purpose space partitioning containers enclosed in separate library. It's a matter of view. Where user should search this functionality for? And for what data should these containers work for?
Memory allocation is purely dealt with by the allocator, so seeing "use of pool allocators" in the to-do list worries me.
There are large number of different data structures and there may be fe. a massive tree with large number of nodes created in the building process and it's better to have pools of nodes than to create each one separately.