Re: [Boost-users] Object pools?

Subject: Re: [Boost-users] Object pools?
From: Ryan McConnehey (mccorywork_at_[hidden])
Date: 2010-02-17 20:50:45

Michele Caini wrote:
> Pool will create objects, pool will release and reclaim objects, and pool will delete
> objects.
>   
If the pool manages the life time of the object then the pool can't 
release the object, correct.  The pool will at most loan the object to 
the user.
> You are looking for something that create objects and forbid about them,
> until you return that objects to the home. Is correct?
>   
Did you mean forget instead of forbid.  The kind of pool I'm talking 
about would only forget about those objects that it released.
It still needs to manage the life time of the objects it didn't release.
> Really, it's possible but it is not as a pool works, simply.
>   
Are you stating that Boost.Pool doesn't work this way or all pools?  Is 
there a definition for a pool that I'm missing.  I thought
a pool was a collection of objects and an object could be provided to 
the user.  The implementation and life time of the object
were left up to the pool.
> Your idea breaks also raii pattern and you risk to have memory leaks,
> because not reclaimed objects maybe be lost during their life time.
>   
In my requirements, to avoid memory leaks, the objects were passed to 
the user with a boost::shared_ptr.

> What about a monostate pattern that globally manages objects as a pool
> and will be destroyed only when program terminates? That's can be a
> valid alternative, or not?
>   
I believe the monostate pattern shares its (static) data.  Wouldn't this 
mean the amount of data can't be increased?  If the data can't be
increased it not as useful to the user when all the objects have been 
used but more are still needed.

Ryan