On Fri, Sep 24, 2010 at 12:04 PM, Branko Čibej <br...@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