Am Wednesday 04 November 2009 04:31:25 schrieb Nigel Rantor:
Reading the above interprocess docs was another reason why I assume you're really talking about augmenting Pool. Those allocators appear like they'd have significant overhead for small objects, which Pool doesn't currently (With the same caveats about me reading the Pool docs correctly).
So, if I understand correctly the wishlist is:
- O(1) de-allocation.
- Arbitrary sized allocations from a single pool.
- Better performance for MT.
well, these are the points that _I_ am missing. I did not research this topic, so there might be many other algorithms with different memory and time complexity characteristics. from what I understand there are also other libraries for that task, at least I was recommended a google library when I brought up this topic earlier. I didn't look at it though. after researching what is out there and more "wishlists" other that mine, one could decide if the current boost.pool interface/concepts is sufficient and could be kept. I had a short look at the implementation of boost.pool and I would not try to ammend the implementation. there are easier ways to implement that sort of thing, particularily using Boost.Intrusive.
I am tired so I'm going to be lazy and say that I can see how you could have multiple strategies in one library that allow people to pick their preference of time vs. space
exactly.
but I'm not immediately sure if you can make an allocation scheme that gives constant-time and space for all operations.
no you can't. (if you meant 0 memory overhead)