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.
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.