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.