Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at