[ apologizes for the somewhat stream-of-conscious nature of these mails ]
On Wed, Sep 22, 2010 at 7:16 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> On Wed, Sep 22, 2010 at 5:35 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> For the C++ folks out there, I've got a question about an approach to
>> take on the object-model branch. At issue is how to wrap the various
>> C structures returned to callers, particularly in a backward
>> compatible manner. Currently, I'm looking at svn_wc_notify_t *. As I
>> see it, there are a few options:
>>
>> 1) Just wrap the pointer to the C struct as a member of the wrapper class.
>> Pros: Easy to implement; lightweight constructor.
>> Cons: Getters would need to translate to C++ types; would need to
>> implement a copy constructor which deep copies the C struct; would
>> also introduce pools, since creating and duplicating C structs
>> requires them.
>>
>> 2) Wrap each C struct member individually
>> Pros: C->C++ complexity is constrained to the constructor,
>> everything else is C++ types
>> Cons: Hard to extend for future compatibility
>>
>> 3) Just pass the C-struct pointer around; don't even bother with a class
>> Pros: Dead simple.
>> Cons: Requires more memory management thought by consumers; not
>> C++-y enough; may introduce wrapping difficulties.
>>
>> I'd like to come up with something consistent, which would be used
>> throughout the C++ bindings. I'm also interested in a solution which
>> ensures the C++ bindings can be used as the basis for other
>> object-oriented bindings models (Python, Perl, etc.)
>
> After lunch, and some thought, it feels like #1 is the best solution.
> This doesn't change the external class interface, which is good, and
> can still provide C++ values to callers who want them. The pool
> issues are a bit messy, but at least the object can manage it's own
> memory (albeit at a significant overhead).
This could get ugly.
Creating and destroying pools all over the place could get ugly, but
it's necessary evil because all of our object creation / duplication
functions all require a pool. An alternative would be a set of
functions returning the size of the object, and then another which
puts the object in a pre-allocated memory location. (These could
theoretically replace the pool argument version of the API, but that'd
be *a lot* of churn.)
The approach would let the C++ allocate the memory (of the correct
size) using whatever scheme it wants, and then do a "placement
initialize" using the second API. If we do go this route, I'd
recommend exposing these as private-to-Subversion, at least initially.
The other option is just pass the C-struct pointer around everywhere,
but then the bindings consumers have to work about this exact same
issue. In other words, it solves it now, but really just pushes the
problem elsewhere.
-Hyrum
Received on 2010-09-22 21:44:57 CEST