Subject: Re: [boost] new library (space partitioning)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2010-08-08 16:32:54
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.