>>>>> Steinar Bang <s...@dod.no>: >>>>> "Hyrum K. Wright" <hyrum_wri...@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.
