On Sat, Sep 25, 2010 at 3:30 AM, Steinar Bang <sb_at_dod.no> wrote:
>>>>>> "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu>:
>
>> 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.
>
> Hm... this sounds very complex and complicated.
>
> What exactly is it you want to do? Have a thin C++ wrapper around C
> objects, where the C objects "do the work"? Why do you want to?
> Ie. what benefit do you expect to get, compared to just using the C
> objects from inside your C++ code?
Returning C objects to the callers of the bindings would require said
callers to worry about managing the memory allocated for those
objects, thus requiring them to care about pools and their lifetimes.
I want to eliminate this requirement of direct management for the
callers, and provide them with objects that "look" like standard C++
objects (with C++ memory management paradigms, etc). Most of these
objects are not functional, but rather informational in nature.
> FWIW the patternt I would have looked at initially, (without actually
> studying the problem your're trying to solve...;-) ) is one of having
> refcounting smart pointers to a reference object. The reference object
> would have one pointer to the underlying C object and a reference count.
>
> The constructor of a smart pointer would up the reference count by one,
> and the destructor of the smart pointer would decrease the reference
> count by one. When the reference counter in the reference object went
> to 0, it would assume that it had no users, and call the C pool code to
> clean up its memory usage.
>
> For creation of the reference objects you have at least two choices:
> - Use some kind of factory
> - Create the C object using the C APIs creation functions in the
> reference object's construct
> (or perhaps a combination of the two)
>
> Its not watertight, but people have been writing good and working
> applications, using this pattern.
And it's this approach that I implemented a couple of days ago. :)
See http://svn.apache.org/repos/asf/subversion/branches/object-model/subversion/bindings/c++/include/Types.h
for the latest incarnation.
-Hyrum
Received on 2010-09-25 16:18:18 CEST