On Fri, Sep 24, 2010 at 12:04 PM, Branko Čibej <brane_at_xbc.nu> wrote:
> 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?
The advantage that JavaHL has is that there is a well-defined boundary
between the consumer (written in Java) and the wrappers. Returned
structures (such as svn_commit_info_t) are converted to Java before
the end of the call down into C++, so we can allocate everything in
the per-API pool (the "request pool"), and not worry about lifetimes.
A C++ application using the C++ bindings doesn't have that limitation,
though we could do the analogue by "converting" the C structs deeply
into C++ objects. But this introduces forward compatibility issues in
the case of growing structs--the entire reason we use the pool-based
creation functions in the first place.
-Hyrum
Received on 2010-09-24 19:31:34 CEST