Re: [boost] new library (space partitioning)

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.