[ This is more thoughts (and questions!) about the work on the
object-model branch. If you don't care about the nuances of such
things, you can stop reading now, and save your cycles for shipping
1.7 work. :) ]
I'm trying to determine the best way to return objects from the
various wrapping classes found in Types.h [1]. At issue here is how
to return NULL values back to callers.
Recall from a previous discussion that these classes simply hold a
handle to the underlying C structure, and then implement getter
methods to enable the caller to pull information out of them. (We may
change the implementation down the road, but the API seems
reasonable.) Currently, we return this information by value, relying
upon compiler optimizations to eliminate unneeded copies, etc. The
problem with this approach is that many of our C structs are
incomplete, that is, they contain only certain subsets of values, with
other values represented as NULL pointers.
This creates a problem when attempting to return these NULL values by
value in the C++ bindings. The "obvious" solution is to return the
problematic values by pointer, but that introduces difficulties of its
own. I see the following options:
1) Return everything by value
Pros: simpler memory management, less overhead (?)
Cons: doesn't allow the return of NULL values, need to establish
conventions to represent NULL objects (an isNull() method?)
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)
3) Some combination of (1) & (2)
Pros: Can return guaranteed existing things by value, potentially
NULL ones by pointer
Cons: Making the distinction between optional and required takes
more effort, a heterogeneous API is more work for callers
I'm leaning toward (2), even though it requires a bit more management
on the part of callers, I think it's the better approach to take.
It's not as clean, but still allows the use of the NULL value, which
callers can use in the normal fashion. I've not explored how this
would impact swig's ability to generate bindings based on the C++
object model, though.
Thoughts?
-Hyrum
[1] http://svn.apache.org/repos/asf/subversion/branches/object-model/subversion/bindings/c++/include/Types.h
Received on 2010-10-12 20:36:23 CEST