4

I was under the impression that an object pool is a design pattern used for managing a group of pre-allocated objects to which a client can request and be returned one of these objects. However, it seems that boost.pool's object_pool class has more to do with lower-level memory management than object management. Why did they go with this name, as opposed to something like memory_pool? Am I under the wrong impression that boost's object pool is really a memory pooling scheme? Or are they essentially the same thing? Also, why hasn't there been a standard implementation of a more high-level object pool pattern?

jwalk
  • 1,120
  • 11
  • 27
  • 1
    Are you thinking of something like a [slab allocator](http://en.wikipedia.org/wiki/Slab_allocation). That is a pattern that keeps some common object properties initialized so that the object is partially constructed in the pool? I think that it would be hard to model *partially* constructed object in C++. How would they be *completed*? An interesting question though. – artless noise Apr 06 '13 at 01:36
  • Are you confusing allocation with construction? – Yakk - Adam Nevraumont Apr 06 '13 at 02:56
  • I have provided an answer which I believe addresses my confusion, although feel free to comment if it sounds like my interpretation of `boost.pool` implementation is wrong. – jwalk Apr 06 '13 at 05:29
  • Hi, thx for the question. I also have the same question. i need an "Object Pool" so that i can reuse objects. does boost provide anything in this direction? or is there any advantage to using `boost::pool` over a simple hand made "Object pool" which simply reuses objects? – weima Jul 03 '13 at 06:56

1 Answers1

5

After reading more thoroughly into the boost.pool documentation, I think I understand my confusion. I'm used to thinking of an object pool implemented as a class which allocates and manages a set of direct objects. Consider,

template<class T>
class object_pool {
private:
  std::list<T*> m_reserved; // holds onto any objects that have been allocated
public
  T *acquire() { /* grabs from reserved list */ }
};

However, it seems boost.pool implements a different concept of object pooling, one used for a completely different purpose than the one as suggested above. boost.pool allocates and manages the underlying memory of the desired object(s), presumably so that it can increase heap performance by means of what it describes as Simple Segregated Storage. It in fact does not follow this concept of the object pool pattern. An explanation on the distinction between the two patterns can be found in the answer to my subsequent question.

Community
  • 1
  • 1
jwalk
  • 1,120
  • 11
  • 27
  • 1
    [This concept](http://en.wikipedia.org/wiki/Object_pool_pattern) is much like a [slab allocator/look-aside cache](http://www.makelinux.net/ldd3/chp-8-sect-2). – artless noise Apr 10 '13 at 22:02