Did you already try .def'ing the functions with the order reversed? I think it should work for your case. Boost.Python uses a simple "first match" approach, I think trying bottom up for functions and member functions, top down for constructors (for weird reasons).
On Thu, Apr 12, 2012 at 9:48 AM, Holger Brandsmeier <brandsme...@gmx.de>wrote: > Dear list, > > I exported the C++ function `sin` both for real and complex numbers > (`float` and `complex` in python / `double` and `std::complex` in C++) > and I noticed that calling `sin(2.3)` gives `(0.7457052121767203-0j)` > so a complex number. Why is that? In which order does boost python > handle overloading of functions anyways? > > > More precisely I exported this function to python > > >>> sin? > Type: function > Base Class: <type 'builtin_function_or_method'> > String Form: <Boost.Python.function object at 0x26358e0> > Namespace: Interactive > Docstring: > sin( (float)arg1) -> float : > > C++ signature : > double sin(double) > > sin( (complex)arg1) -> complex : > > C++ signature : > std::complex<double> sin(std::complex<double>) > > Notice in particular that the `float` version is above the `complex` > version, so if boost::python things this is ambiguous (I don't > condider this abiguous), but even if so I was kind of expecting him to > use the first exported function, not the second. > > Any ideas? > -Holger > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig@python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig >
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
