[boost] Re: Status of Boost.Python docs?

From: David Abrahams (dave_at_[hidden])
Date: 2004-10-05 15:38:55

Jonathan Wakely <cow_at_[hidden]> writes:

> On Tue, Oct 05, 2004 at 10:40:43AM -0400, David Abrahams wrote:
>
>> > OK, it was no problem to fix this. But if run on the complete
>> > operators example, the compiler (gcc 3.4.2 on 686-pc-linux-gnu) chokes
>> > nevertheless. And this time I can't make much sense out of the error
>> > messages. 
>> 
>> > (In case someone is interested, the compiler output is
>> > online at <URL:http://tinyurl.com/5u3rr>.)
>> 
>> error: ambiguous overload for 'operator+' in 'l + r'
>> note: candidates are: operator+(long int, long int) <built-in>
>> note:                 number boost::operator+(const number&, const number&)
>> 
>> GCC claims that the operator+ provided by integer_arithmetic<number>
>> is ambiguous with the one that uses an implicit conversion to int
>> on each side of the operator.  That's a compiler bug; the former is
>> an exact match.
>
> Are you sure?
> (I don't doubt you are, just trying to understand it myself :)
>
> Looks to me as though the exact match would be
>
>     operator+(number&, long int const&);
>
> So either of the overloads given would involve a conversion.
>
> So any bug wouldn't in the overload resolution, but in whatever caused
> boost::python::detail::operator_l<op_add>::apply<L, R>::execute(L&, const R&)
> to be instantiated ... [with L = number, R = long int]
>
> Should there be another overload that doesn't require the conversion?

I *was* sure, but it turns out you guys are absolutely right.  The
example is now fixed and tested.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com