Re: [boost] new library (space partitioning)

Subject: Re: [boost] new library (space partitioning)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2010-08-09 12:35:20

Mathias Gaunard wrote:
> Le 08/08/2010 21:32, Adam Wulkiewicz wrote:
>
>> 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?
>
> Boost.Geometry works with un-intrusive concepts, and allows to use
> arbitrary types.

I'm talking about something different. There are many fields where 
spacial indexes are used. Does user who wants to implement an algorithm 
extracting features from the picture or searching data in the database 
should look for needed data structures somwhere deep in the geometry 
library? Or maby, the geometry library should use functionality provided 
by the space partitioning library (both using the same concepts)?

>> 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.
>
> I don't understand your point.
> Your container wants to allocate memory, it uses its allocator
> parameter. The user wants to change the way memory is allocated, he
> changes that parameter.
>
> You can indeed allocate all the memory in one go at construction, I
> don't see why that requires a pool allocator.

Yes, you're right. Although, there may be more than one allocators used 
in the tree building algorithm. There may be allocators for tree nodes, 
temporary objects at each recursive step and for objects in leafs. I 
thought about implementing this kind of container later and wanted to 
select proper allocators internally automatically (because it 
complicates the interface and the user must know about the internal 
details) but this is just a proposition.