Status of Boost.Python docs?
Hi, I tried to become acquainted with Boost.Python. But even the examples in the documentation won't compile. The examples leave the impression as if they are untested because they contain quite obvious errors. For instance, from libs/python/doc/v2/operators.html (current CVS): [...] struct number : boost::integer_arithmetic<number> { number(long x_) : x(x_) {} operator long() const { return x; } number& operator+=(number const& rhs) { x += rhs } number& operator-=(number const& rhs); { x -= rhs } number& operator*=(number const& rhs) { x *= rhs } number& operator/=(number const& rhs); { x /= rhs } number& operator%=(number const& rhs); { x %= rhs } long x; }; [...] There are spurious semicolons after the argument list of operators -=, /=, and %=. On the other hand, there are semicolons missing in the bodies of the in-place operators... 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>.) The regression test table at <URL:http://boost.sourceforge.net/regression-logs/cs-Linux.html> shows a runtime failure of the operators test for gcc 3.4.2. So the corresponding C++ module could be compiled, in contrast to the example from the docs. The user-level report at the meta-comm site <URL:http://tinyurl.com/4ebxv> (last updated on Aug 11) shows that the operators test passed with gcc 3.4.1. Since the regression tests show some problems with gcc 3.4.2, I can't be completey sure whether the errors I see are due to a compiler / platform problem or to a erroneous example. Since the example contained errors that had nothing to do with Boost.Python and the compiler and since examples from the tutorial also failed I suspect the latter. Can someone explain how this particular example needs to be changed so it can be compiled? Will the examples in the docs be checked before the upcoming release? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes:
Hi,
I tried to become acquainted with Boost.Python. But even the examples in the documentation won't compile. The examples leave the impression as if they are untested because they contain quite obvious errors.
Some of them are untested. You can find assuredly tested examples in libs/python/test/*.[cpp|py]
For instance, from libs/python/doc/v2/operators.html (current CVS):
[...] struct number : boost::integer_arithmetic<number> { number(long x_) : x(x_) {} operator long() const { return x; }
number& operator+=(number const& rhs) { x += rhs } number& operator-=(number const& rhs); { x -= rhs } number& operator*=(number const& rhs) { x *= rhs } number& operator/=(number const& rhs); { x /= rhs } number& operator%=(number const& rhs); { x %= rhs }
long x; }; [...]
There are spurious semicolons after the argument list of operators -=, /=, and %=. On the other hand, there are semicolons missing in the bodies of the in-place operators...
Thanks for the report; fixed in CVS.
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.
The regression test table at <URL:http://boost.sourceforge.net/regression-logs/cs-Linux.html> shows a runtime failure of the operators test for gcc 3.4.2. So the corresponding C++ module could be compiled, in contrast to the example from the docs. The user-level report at the meta-comm site <URL:http://tinyurl.com/4ebxv> (last updated on Aug 11) shows that the operators test passed with gcc 3.4.1.
Since the regression tests show some problems with gcc 3.4.2, I can't be completey sure whether the errors I see are due to a compiler / platform problem or to a erroneous example.
The errors you're seeing now are a compiler bug.
Since the example contained errors that had nothing to do with Boost.Python and the compiler and since examples from the tutorial also failed I suspect the latter.
Can someone explain how this particular example needs to be changed so it can be compiled?
The changes you mentioned (removing the incorrect semicolons and adding them within the operator function bodies) ought to be enough.
Will the examples in the docs be checked before the upcoming release?
Doubtful, unless someone volunteers. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes:
On Tue, Oct 05, 2004 at 10:40:43AM -0400, David Abrahams wrote:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
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 :)
I was sure, but I was wrong and you guys are both right. The example needs to be changed: struct number : boost::integer_arithmetic<number> { explicit number(long x_) : x(x_) {} operator long() const { return x; } template <class T> number& operator+=(T const& rhs) { x += rhs; return *this; } template <class T> number& operator-=(T const& rhs) { x -= rhs; return *this; } template <class T> number& operator*=(T const& rhs) { x *= rhs; return *this; } template <class T> number& operator/=(T const& rhs) { x /= rhs; return *this; } template <class T> number& operator%=(T const& rhs) { x %= rhs; return *this; } long x; }; And, incidentally, class_<number>("number", init<long>()) ^^^^^^^^^^^^ -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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? jon -- "Entropy requires no maintenance"
Jonathan Wakely <cow@compsoc.man.ac.uk> 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
participants (3)
-
Christoph Ludwig -
David Abrahams -
Jonathan Wakely