Boost logo

Boost :

From: Christoph Ludwig (cludwig_at_[hidden])
Date: 2004-10-05 10:48:57

On Tue, Oct 05, 2004 at 10:40:43AM -0400, David Abrahams wrote:
> Christoph Ludwig <cludwig_at_[hidden]> 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:>.)
> 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?




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