>>>>> Steinar Bang <sb_at_dod.no>:
>>>>> "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu>:
>> 2) Return everything by pointer
>> Pros: can represent the NULL value, potentially less memory overhead
>> Cons: more complex memory management (caller must delete returned value)
> Um... why must the caller delete the returned value? I thought you were
> using refcounting smartpointers?
Boost has two such (shared_ptr which is non-intrusive, and intrusive_ptr
which is).
http://www.boost.org/doc/libs/1_44_0/libs/smart_ptr/smart_ptr.htm
http://www.drdobbs.com/184401507
But personally, I wouldn't have used either, because the templated smart
pointers are more complicated than smart pointers have to be, and it
would create a dependency to boost (which btw is a nice library to have
dependencies to, and contains stuff the Standard library should have
contained, instead of what it actually contains... but that's a
different story...).
What I would do is to:
- create a base class ReferenceCountedObject with an increment() method
and a decrement() method, and a protected virtual
freeWrappedPointer() method
- I would also create a base smart pointer class for
ReferenceCountedObject* that
- In its copy constructor(s) would increment the referenced object's
reference count
- In the assignment operator would decrement the reference count of
any object the pointer is already pointing to, and increment the
reference count of the assigned object
- In its destructor, decrement the reference count of the referenced
object
If possible, I would make the constructors and assignment operator
protected
- I would inherit from ReferenceCountedObject to make all of my wrapper
classes
- The wrapper classes would implement freeWrappedPointer() to free the
SVN API object they have a pointer to in the correct manner
- I would inherit from the base smart pointer class to create one smart
pointer for each wrapper class. These smart pointers' copy
constructors and assignment operators would delegate to the base
class for copy constructors and assignment, and implement wrapper
class specific de-referencing operators
- I would create a singleton class wrapping the API, functioning as a
factory for all API objects
- I would disallow making wrapper class instances (either by using pure
virtual classes in the API, and hidden implementation classes, or by
giving the wrappers private constructors and making the singleton API
wrapper class a friend. I think I prefer the pure virtual with
hidden implementation approach)
The reason for not creating the wrapper objects directly is that you
would like to have control over the initial increment value. Another
reason is that having such a singleton class maps nicely to wrapping a C
API.
Received on 2010-10-13 21:29:35 CEST