On Tue, Oct 05, 2004 at 10:40:43AM -0400, David Abrahams wrote:
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes: [...]
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? This particular error message starts In static member function `static PyObject* boost::python::detail::operator_l< op_add>:: apply<L, R>::execute(L&, const R&) [with L = number, R = long int]' whence an exact match would be operator+(number const&, long int). And since number has both a non-explicit constructor taking a long and a operator long() const, I don't see why either of above operator+ overloads should be a better match. Am I missing something? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html