Re: Making smart pointers a bit smarter

On Sun, 8 May 2005, Kenneth Duda wrote:

> "None" is much friendlier than a wrapped NULL smart pointer --- it's
> easy to test for "None", and if you try to use it as a pointer, you
> get a sensible Python exception (rather than a SEGV).
>
> All of this is fine --- the reason I'm writing is I would like to make
> this improved smart pointer wrapping the default behavior of SWIG.
> Before I spend the time to do so, I wanted to guage the interest level
> from the SWIG maintainers --- is the patch likely to be accepted
> (assuming I code it competently), or is it something you're not
> interested in (i.e., is there a good reason to not do this)?

I understand the motivation for doing this, but I also see some
downsides, and some ways to protect against segfaults while avoiding the
downsides.

Sometimes in C++ one creates a smart pointer that points at NULL and
subsequently modifies it, using methods of the smart pointer class.  This
way of doing things would be impossible with None.  Also, there is
potential for loss of information and for throwing away a useful object.
This isn't an issue for a smart pointer that contains a pointer as its
sole data member, which is returned by operator->, but not all smart
pointers are like that.  Perhaps operator-> returns NULL but the object is
full of information and has other methods that are still very useful
(perhaps I can decrement my pointer and it will now point at something;
perhaps operator-> is a minor part of what the class does, and returns
NULL more often then not).

Another problem is that the code you want to generate will call operator->
on NULL smart pointers.  The code I'm wrapping has smart pointer classes
whose operator-> checks whether the pointer is null and throws an
exception if it is.  So I would never wind up with None; I would get an
exception instead, which I don't think would even be caught (as bad as a
segfault).

There's also potential for confusing a non-null pointer to a null smart
pointer with a null pointer to a smart pointer.  In fact, how would I pass
a null smart pointer by value?  Pass None?  The default "in" typemap will
reject this as a null pointer (to smart pointer).

Why not check for nullness on the other end, in the wrapper functions that
dereference the smart pointers?  I think that that avoids all these
problems.  It doesn't allow you to test for nullness by comparing to None,
but you can always compare foo.__deref__() to None, and smart pointers
often provide methods for testing for nullity.

Better yet, why not move much of smart pointer support out of C++ and into
the target language?  Python methods could simply call
self.__deref__().Func(), which would automatically protect against null
pointers.  I've been interested in this for another reason: smart pointer
support greatly increases the size of wrapper code because lots of methods
get wrapped multiple times.

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