[boost] Re: Including abs() in rational.hpp

From: Ed Brey (brey_at_[hidden])
Date: 1999-12-09 09:28:50

Kevlin Henney wrote:
> 
[...]
> > I sort of lean towards the latter, as code like
> >
> >     using std::abs;
> >     using boost::rational;
> >     int n = -1;
> >     rational<int> r(-1);
> >     n = abs(n);
> >     r = abs(r);
[...]
>      However, one use that would fall foul of expectation would be full
>      explicit qualification:
> 
>           r = std::abs(r);
> 
>      This suggests that abs should be in std. However, my reading of the
>      standard says that only template specialisations of library templates
>      are permitted in std; the abs for rational is a separate overload
>      rather than a specialisation, so I think that such an overload would
>      not be permitted. Can anyone confirm my reading of this?

Conform or deny I cannot.  But I can offer other alternatives:

namespace boost { namespace rational {
    template <typename Int> class rational<Int> {...};
    template <typename Int> inline rational<Int> abs(rational<Int> r)
{...}
}}

or

namespace boost {
    template <typename Int> class rational<Int> {
        ...
            friend abs(rational r) {...}
    };
}

The user code would then look like this:

    using std::abs;
    using namespace boost::rational;
    int n = -1;
    rational<int> r(-1);
    n = abs(n);
    r = abs(r);

"using namespace" becomes just "using" if the second option is used.

The first first option follows existing practice in boost; however, in
this case I like the second option better.  All that's needed is a
plain old lookup, and abs still gets found.  IMO, abs should be a
friend, since conceptually it should have access to any private
hints.  Even though there will probably never be any, at least the
access rights are set up properly from day one.

The requirements for rational's abs are different than that for std's
abs, and so there are different constraints.  std::abs needs to work
with many different data types, including built-in types, which forces
it to be a global, non-friend function.  rational::abs need only work
with type rational, and so it has the luxory of being a friend
function defined within rational.  We might as well take advantage of
capability.