overloaded functions and order of arguments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

overloaded functions and order of arguments

Holger Brandsmeier
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
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: overloaded functions and order of arguments

Ralf Grosse-Kunstleve
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 <[hidden email]> 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
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig


_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: overloaded functions and order of arguments

Holger Brandsmeier
Indeed, reversing the order works. Thanks also for the explanation.

This required to change my template metaprogramming code which I use
to export the classes. This is not optimal as I want to know that no
compiler errors occur for `double` before I get potentially more
complicated compiler errors for `std::complex<double>`, but I will
probably have to live with that.

-Holger

On Thu, Apr 12, 2012 at 19:03, Ralf Grosse-Kunstleve
<[hidden email]> wrote:

> 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 <[hidden email]>
> 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
>> [hidden email]
>> http://mail.python.org/mailman/listinfo/cplusplus-sig
>
>
>
> _______________________________________________
> Cplusplus-sig mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/cplusplus-sig
_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Loading...