On 24.09.2010 18:43, Hyrum K. Wright wrote:
> All of the Pools used to hold the child objects are children of the
> global parent (created with NULL as the parent pool). As such, they
> are independent of each other, and won't have destruction order
> issues. It's pretty wasteful in terms of the memory overhead, but
> meets the goal of having each object have it's own pool, and control
> it's own lifetime independent of other objects.
I'm questioning that specific goal. What do you gain by it?
I'm not convinced that it is a good idea to do this. If you keep the C++
wrappers minimal, i.e., wrap every C structure in a thin sheet of C++
and hope for the best -- then I have a nagging suspicion that managing
pool lifetimes will have to be explicit.
On the other hand, you could take a more high-level approach (like
JavaHL?) and not tie the object model to the current API too much. Then
I could imagine, e.g., having an "SVNClient" object that does all the
pool management. It's generally more easy to deal with pools on a
slightly higher level than per-object, wouldn't you say?
> Pool are certainly un-C++-like, but our APIs don't help to much
> either. To allocate (or duplicate) these structures, we require
> callers to provide a pool, instead of a generic allocation mechanism.
> If we did the latter, we could easily put these objects into memory
> managed "natively" by C++, but because we don't, a Pool is required.
> That's really the only reason to use pools in these objects.
Actually this pool-instead-of-allocator restriction comes from APR ...
early in the design of APR, generic allocators were dropped in favour of
pools, which then force their lifetime behaviour on all applications
that use them. I believe one of the reasons for this was allocation
speed, and another was that pools fit a stateless HTTP server
implementation perfectly ... though they're not too handy for other
kinds of applications.
-- Brane
Received on 2010-09-24 19:04:55 CEST