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

From: Moore, Paul (Paul.Moore_at_[hidden])
Date: 1999-12-16 05:15:13

From: Alan Griffiths [mailto:alan_at_[hidden]]
> Three cases:

[ I suppose I started this, so I'll jump in here]

> /1/ Change name lookup rules so that boost::abs is found - without or
> with "std::".  (I think we agree this is wrong.)

I'd agree this is wrong. If you explicitly ask for std::abs(), that's what
you should get.

> /2/ Require any client code that references an abs function in a class
> where an abs member function exists to use a proxy function like: 
> 
>     template<typename number_type> 
>     number_type proxy_abs(number_type x)
>     { using std::abs; return abs(x); )
> 
> (I guess this is what you intend.  However, I think this would be a
> maintenance disaster.)

This is what I do (modulo compiler bugs) in the rational class. It is nasty,
but I don't see it as a big issue. Then again, I don't view the rational
class as "client" code - it's library code (as will be all generic stuff, in
principle), and as such needs to take careful account of such issues.

But there is a good case for a book on "writing C++ libraries", which would
be VERY diferent from existing books on writing C++ "client" code.

Until good principles on how to write C++ libraries are common knowledge, it
probably needs a comment, though (and maybe even after).

> /3/ Allow std::abs to be overloaded on UDTs.  (Maybe I've not seen the
> problem with this approach - AFAICS the only issue is with 
> the letter of the standard.)

I do think that allowing this seems innocuous (excepting any "purity of
std::" issues). But as long as users *can* put an abs() implementation in
the UDT namespace, library designers *must* take care to cater for it. As
such, the workaround in (2) above is still necessary (no, I won't let you
say "my generic class only works if the template parameter's abs() function
is defined in std::" :-) :-))

So allowing this doesn't, in practice, gain the library designer anything.
And user-level code shouldn't be worrying about this level of genericity
anyway.

Therefore, there isn't any advantage sufficient to warrant changing the
standard.

Just my thoughts,
Paul.