Re: [Swig-user] C++ STL for python: iterators, functors, algorithms, and of course containers

[Rob S. <rob...@si...>]

From: Josh Cherry <jc...@nc...>
> On Thu, 3 May 2007, Eric Mahurin wrote:
> > On 5/3/07, Rob Stewart <rob...@si...> wrote:
> >> From: "Eric Mahurin" <eri...@gm...>
> >>
> >> You have to know how the operators map to the target language.
> >> For Python, you'd do things like this:
> >> 
> >> %rename(__add__) SAPrice::operator +(SAPrice const &);
> >> %rename(__iadd__) SAPrice::operator +=(double);
> >> %rename(__sub__) SAPrice::operator -(SAPrice const &);
> >> %rename(__isub__) SAPrice::operator -=(double);
> >> %rename(__neg__) SAPrice::operator -();
> >> %rename(__mul__) SAPrice::operator *(SAPrice const &);
> >> %rename(__imul__) SAPrice::operator *=(double);
> >> %rename(__div__) SAPrice::operator /(SAPrice const &);
> >> %rename(__idiv__) SAPrice::operator /=(double);
> >> 
> >> %rename(__eq__) SAPrice::operator ==(SAPrice const &);
> >> %rename(__ne__) SAPrice::operator !=(SAPrice const &);
> >> %rename(__lt__) SAPrice::operator <(SAPrice const &);
> >> %rename(__gt__) SAPrice::operator >(SAPrice const &);
> >> %rename(__le__) SAPrice::operator <=(SAPrice const &);
> >> %rename(__ge__) SAPrice::operator >=(SAPrice const &);
> 
> These happen "automatically" thanks to python/pyopers.swg, right? 
> Handling of inplace operators is actually more than a %rename.

Do they?  How would I know?  I find no documentation of
pyopers.swg.  I knew nothing of it.

Does one simply %include "pyopers.swg" early in the interface
file and the rest happens automagically?

> >> %rename(__radd__) operator+(double lhs, SAPrice const & rhs);
> >> %rename(__rsub__) operator-(double lhs, SAPrice const & rhs);
> >> %rename(__rmul__) operator*(double lhs, SAPrice const & rhs);
> >> %rename(__rdiv__) operator/(double lhs, SAPrice const & rhs);
> 
> I don't think these will work.  More generally, handling of non-member 
> overloaded operators won't work with just a %rename (that will produce a 
> non-member Python function, which can be called directly but will not 
> affect the behavior of the operator).  Using %extend to add the method to 
> the class is one way to deal with this.  Conceivably, SWIG could automate 
> this.

They compiled fine, though I confess I haven't tested the
result.  If it isn't handled automatically, or via some directive
to trigger it, it should be.

> > My question though was more about whether there are standard conventions
> > about mapping C++ operator methods that don't have good equivalents in the
> > target language.  The main ones that come to mind are:
> >
> > operator*()
> > operator->()
> > operator->*()
> > operator=()
> 
> SWIG's automatic smart pointer handling is relevant to some of these.
> 
> operator++() and operator--() are also issues for Python, and particularly 
> relevant to C++ interators.  I also find it useful to rename operator bool 
> to __nonzero__ for Python, which is nice for "if" clauses.

So how are iterators wrapped via SWIG for the general case?  That
is, if one doesn't want to use iterators in an STL container, but
in another class with compatible iterators, how can one get
iteration in Python?

-- 
Rob Stewart                           rob...@si...
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;