Hi, of course, in my opinion pool has to manage objects life time. However sharing objects with pool owner by shared ptr seems to be a good idea, because pool still manages objects life time. Using shared pointer also inside pool solves the problem, maybe. It is correct?
----- Reply message -----
Da: "Ryan McConnehey" <mccorywork@gmail.com>
Data: gio, feb 18, 2010 02:50
Oggetto: [Boost-users] Object pools?
A: <boost-users@lists.boost.org>
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
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users