Boost logo

Boost :

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:>.)
>> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at