Re: Making smart pointers a bit smarter

On Mon, 9 May 2005, Kenneth Duda wrote:

> This sounds like it would be better.  How would you imagine checking
> for nullness, if testing operator->() for NULL can't be trusted?  I
> suppose I could wrap the null check in a try block and treat any
> exception as equivalent to NULL.  Would you recommend that?

I was imagining using operator->.  I was thinking that it's not a problem
if testing is done here, which is sort of true.  Right now I get basically
the behavior we're talking about because my operator-> throws an
exception, which gets caught by the exception handling I've set up for
everything using %exception and turned into a target language exception.
If this test were to wind up inside of the "try" block set up by
%exception, things would continue to work the same for me even without
special exception handling here.

> Let me see if I understand this suggestion. It means eliminating most
> methods of the wrapped C++ smart pointer, leaving only __deref__ and
> __notzero__ (that could do the NULL test safely); then, modify the
> python wrapper of the smart pointer so instead of saying
>
>    def someMethod(*args): return _MyLibrary.MyClassSmartptr_someMethod( *args )
>
> it would say
>
>    def someMethod(self, *args):
>       if self: return self.__deref__().someMethod( *args )
>       else: raise NullPointerException()

That's basically what I had in mind.  I was imagining simply doing

def someMethod(self, *args):
    return self.__deref__().someMethod( *args )

but your way yields a more appropriate exception.  Also, wrappers for any
C++ methods of the smart pointer itself should of course remain as they
are; only wrappers for the methods of the pointee get this treatment.  I'm
not sure whether __notzero__ is needed (and did you mean __nonzero__,
which is a special Python method).

As I said, my reason for interest in this approach is wrapper size.  I
recently reduced my shared library size by 25% by getting rid of proxies
for reference counting smart pointers (wrapping is especially expensive
because all of the need to wrap even those methods of the pointee that are
defined in base classes).

Josh

--
Joshua L. Cherry, Ph.D.
NCBI/NLM/NIH (Contractor)
jcherry <at> ncbi.nlm.nih.gov
_______________________________________________
Swig maillist  -  Swig <at> cs.uchicago.edu
http://mailman.cs.uchicago.edu/mailman/listinfo/swig