>>>>> "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?
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.
Received on 2010-09-25 10:30:50 CEST