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