[boost] Re: Rational Numbers - abs() again

From: Paul Moore (gustav_at_[hidden])
Date: 1999-12-18 18:32:45

From: Beman Dawes [mailto:beman_at_[hidden]]
>
> Here is a report on compiling rational_example.cpp with Metrowerks
> CodeWarrior 5.2:
>
> *  #ifdef _MSC_VER is true, causing the Microsoft hacks to be
> invoked, which of course fail with the more standards conforming CW
> compiler.
>
> Several companies (Metrowerks, Intel, at least, probably more)
> predefine _MSC_VER in an attempt to be compatible.  Sigh.

Grrr. I think I'd blame them. If they define _MSC_VER, they should be
compatible. Bugs and all. After all, most people only use _MSC_VER as a way of
protecting bug-workarounds...

> *  After commenting out the above, tried again and got:
>
> Error   : illegal access to protected/private member
>  (instantiating: 'boost::?$abs_at_H(const boost::rational<int> &)')
> rational.hpp line 299       return rational<IntType>(abs(r.num),
> r.den);
>
> (r.num) was underlined.
>
> *  After commenting out "private:" to hack around the above, the
> compile was clean.

I think this may be a problem in the class. I got mingw32 (GCC) sort-of working
last night, and found that the line

    friend rational abs(const rational& r);

was rejected. Try

    template <typename IntType> friend
    rational<IntType> abs(const rational<IntType>& r);

Template friend? Friend template? Something like that, which it looks like MSVC
doesn't support (yet again).

> *  Ran apparently OK with the output:
>
> 1/2+1/2=1/1
> 1/1-1/2=1/2
> 2/1*1/2=1/1
> 1/1/1/2=2/1
> abs(-1/2)=1/2
> 2 * 2147483647/2=2147483647 (rational: 2147483647/1)
> pi = 3.14286 (nearly)

That looks about right. There are a load of asserts in there, too, which all
seem to have worked.

> Sorry; I was pressed for time and did nothing more.
>
> Hope the above helps.

That's fine - it does help a lot.

Frankly, it looks like the class is fine apart from the abs() stuff. I propose
that abs() is removed from the class definition - at least pending a workable
resolution, which doesn't break (or get broken by) current compilers. After all,
the internals are sufficiently exposed (via numerator() and denominator()) to
allow concerned users to write their own version. I don't think abs() in itself
is important enough to hold things up this much. (Although I do think that the
issue of being able to write workable functions *like* abs() is important and
should be resolved).

Paul.