Brent R. Matzelle wrote:
> --- Justin Erenkrantz <jerenkrantz@apache.org> wrote:
>>I also would consider that the pool should be passed to the
>>constructor of each class. I'm not entirely happy that it does a
>>svn_pool_create(NULL). The issue is that pools are hierarchical
>>and
>>you're going to lose that aspect. At the very least, allow for a
>>constructor where the pool parameter is passed in.
>
> I am not sure what advantage using hierarchical pools would make
> here.
I'm not very familiar with APR, I'm afraid, so here I'm stating what is
possibly obvious to everyone else. Please correct me if it's incorrect.
The purpose of APR pools is to remove the need for explicit cleanup,
correct? You create and destroy a pool in the same scope (around a loop
over calls to a function that uses it, for example). Memory allocation
automatically causes a matching deallocation when the containing pool is
destroyed. Other operations allocating per-pool resources have common
patterns where you allocate and do a apr_pool_register_destructor() (or
whatever its called) at the same point in the code. They are
hierarchical - pools can have subpools, etc.
C++ has a common pattern called "guards" or "monitors" - you create a
small class that handles the allocation and deallocation.
boost::scoped_ptr<> for memory, boost::mutex::scoped_lock for mutexes,
etc. They are on the main program stack, so returning or throwing an
exception or whatever implicitly calls the destructor and makes the
deallocation happen. They are also hierarchical, since the stack is.
When writing pure C++ code, APR's pool concept is pretty redundant. The
guards accomplish the same thing in a slightly simpler/less error-prone
way - there's no need to ever explicitly remove the pool, it happens
automatically when you leave the scope.
When C++ code calls C code...is using subpools important? I would say
no, because the constructor/destructor thing will already make sure the
"subpool" is destroyed appropriately. I think it's more important to
hide the pool stuff as much as possible - it's not the C++ way of doing
things, and making this feel more C++-like is the whole point of SvnCpp.
--
Scott Lamb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 26 02:07:06 2002