> Agree with the decision to #ifdef it... This might be worse than
> first-match, and the overload-order-bug has been around a long time
> without surfacing.
I wouldn't say it is a bug, more a missing feature. Dave and I knew
about the drawbacks from the start, but we didn't have the time for the
r) After writing all that I'm inclined to have a closer
look at the luabind implementation.
-t
Ralf
- Original Message
From: troy d. straszheim
To: Development of Python/C++ integration
Sent: Thursday, March 19, 2009 12:27:56 PM
Subject: Re: [C++-sig] strange behavior wi
string options
(http://www.boost.org/doc/libs/1_38_0/libs/python/doc/v2/docstring_options.html).
I could do that if necessary.
Ralf
- Original Message
From: troy d. straszheim
To: Development of Python/C++ integration
Sent: Thursday, March 19, 2009 12:27:56 PM
Subject: Re: [C++-sig]
Ralf W. Grosse-Kunstleve wrote:
The comprehensive solution sounds like a project. Do we have someone to work on
this?
I'm asking because I think Troy's proposed simple solution is better than the
status quo.
I'm willing to work on it. I'd have to look at Daniel W's code to see
if I want t
day, March 18, 2009 12:15:15 PM
Subject: Re: [C++-sig] strange behavior with respect to numeric and
Booleanoverloads
on Wed Mar 18 2009, "troy d. straszheim" wrote:
> The current rule for overload resolution are simply 'first match in reverse
> order of
> registration&#
on Wed Mar 18 2009, "troy d. straszheim" wrote:
> The current rule for overload resolution are simply 'first match in reverse
> order of
> registration'. You could relatively easily make this 'first match in forward
> order of
> registration'. The library currently has no notion of one func
Very nice analysis of the pros-and-cons!
> Maybe somebody else has more ideas on this. I think you could tighten
> up the automatic conversion rules (like the > patch below does for
> int and bool), so that one would have to clarify at the call site
> which function you're calling:
>
> >> f(f
So, this isn't just a bool-int issue, you can get the same thing with
int and double:
std::string takes_bool(bool b) { return "bool"; }
std::string takes_int(int b) { return "int"; }
std::string takes_double(double b) { return "double"; }
BOOST_PYTHON_MODULE(overload_resolution)
{
I have a quasi-fix for this to the library itself, (see diff below)
buuut it breaks a certain case: if you have a wrapped c++ function that
takes a bool, and you try to pass it an int, you get a
ArgumentError: Python argument types in
builtin_converters_ext.rewrap_const_reference_b
range behavior with respect to numeric and
Booleanoverloads
On Monday 16 March 2009 22:52:16 Ralf W. Grosse-Kunstleve wrote:
> [...] Boost.Python 2 was written when the Python bool type still
really
> was an int (Python 2.2). [...]
On Tuesday 17 March 2009 06:40:14 Roman Yakovenko wrote:
> Python
10 matches
Mail list logo
