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