Hi Michele,
I Don't share your concerns regarding memory leaks with Ryan's idea.
He says he will use shared_ptrs. If the management class always holds
on to a copy of the pointer and so does whoever "checked out" an
object, the object should be guaranteed to not be destroyed if only
pool or outside holder is destroyed, but should be guaranteed to be
destroyed when both are destroyed.
Best,
Dee
On Thu, Feb 18, 2010 at 12:45 AM, Michele Caini
Il 17/02/2010 17:18, Ryan McConnehey ha scritto:
michele.caini@gmail.com wrote:
Simply, That's not as a pool have to work. You are looking for something that is a pool but working not as a pool does. Then what is the definition of a pool? Do you mean that I'm looking for something that is a pool but doesn't work like a Boost.pool?
Ryan
No, sorry. I mean that pool has responsability for manage offered objects, and so it manages them along their life time. Pool will create objects, pool will release and reclaim objects, and pool will delete objects. That's all.
You are looking for something that create objects and forbid about them, until you return that objects to the home. Is correct? Really, it's possible but it is not as a pool works, simply.
Your idea breaks also raii pattern and you risk to have memory leaks, because not reclaimed objects maybe be lost during their life time. So, in my opinion, it is not a good idea. I think that is better to create a pool of object during pool construction, so delete them during destruction, eventually resizing pool during use.
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? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users