From: Paul Moore (gustav_at_[hidden])
Date: 2001-02-07 15:27:04
On 5 Feb 2001, at 17:01, Beman Dawes wrote:
> At 08:28 PM 2/5/2001 +0000, Paul Moore wrote:
> >I've uploaded a new version of the rational numbers library to the
> >boost vault (folder rational, file rational_2001-02-05.zip).
> I ran the Win32 regression tests after Jens updated the CVS. Borland,
> Metrowerks, Microsoft, and Microsoft/STLport compilers worked on both
> rational_test and rational_example.
> GCC fails twice, and Intel fails once. See logs below
Jens already picked up on, and fixed, one of the gcc failures (the
library supplied with 2.95.2 doesn't have ios_base). The other is a
gcc library issue again, affecting the test suite - there is no
stringstream, so the IO tests don't work. They can be hacked to
work with sstreams, which is what I did temporarily while I was
testing. Hmm, I suppose a longer-term solution may be to include
either sstream or stringstream, and typedef the one we have
Is there a config flag saying whether stringstreams exist? There
isn't one in the 1.20.1 release that I could find...
I'll have to look at the intel one...
> ** Intel C++ 5.0
> c:/boost/site/libs/rational/rational_example.cpp(66) : error: no suitable
> conversion function from "boost::rational<int>" to "int" exists
> assert(abs(minus_half) == half);
This implies that abs() isn't finding the version which has a rational
parameter, implying a Koenig lookup problem. That would probably
be related to the "if _MSVC_VER" (or is it BOOST_MSVC in your
version?) hack at the top of rational_example.cpp. There's a new
config flag which says whether the compiler supports Koenig
lookup - please change to use this and see if that helps. I can't use
it as it's not in 1.20.1 and I don't have the CVS cersion.
> c:/boost/site/boost/rational.hpp(442) : error: class "boost::bad_rational"
> has no suitable copy constructor
> throw bad_rational();
Doesn't this say that bad_rational() isn't copyable? But it's derived
from domain error, so that implies that domain error is *also* not
This seems like a library/compiler bug. I can't think how I would
work around it...
Hope this helps, thanks for the test reports,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk