SWIG and C++

[Kevin Dahlhausen]

Yes, but it's kind of hacky at the moment.  You have to remap each of the
overidden functions to a different exported name.  Then create a python
function of the correct name that looks at the input paramters and
dispatches the current function.  I didn't think of this, I just use it.
The FLTK wrappers on Sourceforge (pyfltk.sourceforge.net) use this
method.

I'm looking into the Boost Python Library, which supports this and also
allows subclassing of C++ classes in Python.


In article <mailman.981632045.28779.python-list at python.org>, "Toby J
Sargeant" <tjs at mail.csse.monash.edu.au> wrote:

> On Thu, Feb 08, 2001 at 11:02:27AM +0100, Pierre Puiseux wrote:
>> 
>> Hello,
>> 
>> is it possible with SWIG, to import in python a C++ class with 2
>> methods WITH THE SAME NAME but with different arguments.For instance :
>> //file truc.h
>> class truc
>> {...
>>         void mymethod(int, int); void mymethod(float);
>> }
>> //
>> 
>> //File : truc.i
>> %module truc
>> 
>> %{
>> #include "truc.h"
>> %}
>> 
>> %include truc.h
>> //
>> 
>> //here is the swig command and the error message :
>> >swig -c++ -shadow -python truc.i Generating wrappers for Python truc.h
>> >: Line 17. Function truc_mymethod (member mymethod) multiply defined
>> >(2nd definition ignored).
>> 
>> Thanks
> 
> From memory, the answer is yes, you can. You might like to look at the
> sip files for something like PyQT to find out how, though. I don't know
> why what you're doing isn't working.
> 
> One caveat to this that affected me when I was playing with PyQT that
> may still be true is that if you have two methods that have the same
> number of arguments, and all the arguments of the second method are
> castable to the types of the arguments in the first, then the sip
> wrapper will blindly do the cast, and end up calling the first method,
> even though the types of the arguments you pass match the signature of
> the second.
> 
> The particular example I'm referring to is
> 
> QWMatrix::map(int,int) vs. QWMatrix::map(float,float)
> 
> and the net result was that any floating point values passed to map()
> were implicitly cast to ints, rather than using the floating point
> version.
> 
> Toby.
>