RE: [boost] rational.hpp - abs() again

From: Moore, Paul (paul.moore_at_[hidden])
Date: 2001-01-24 08:55:24

From: Gabriel Dos Reis [mailto:Gabriel.Dos-Reis_at_[hidden]]
> "Moore, Paul" <paul.moore_at_[hidden]> writes:
> 
> [...]
> 
> | More importantly, the impression I get is that too many 
> | compilers are broken with respect to the using statement
> | at [1]. Either they don't put abs() into std::, or (gcc)
> | they ignore using statements at function scope.
> 
> Which version of GCC ignores usingd-declaration at function scope?

Not sure. 2.95.x I believe, but the fix was supplied to me by someone else,
on the basis of problems. I only have MSVC for testing (and one machine I
can occasionally get to with Borland and mingw).

> It is well known that GCC-2.95.x's implementation of the standard
> library is a masquarad as it doesn't really put its library in std::.
> However for that series, saying `using std::abs' effectivelly brings
> the corresponding function (::abs) into scope.

I only have mingw (gcc 2.95.2) to test with, but my general feeling is that
in that case the library issues are so bad as to make me wonder whether it
qualifies as a C++ compiler at all :-( [Broken std:: implementation,
-fhonor-std doesn't work, no <limits>, no stringstreams, ...]

This issue boils down to a judgement call as to how far we should go in
pushing the limits of the C++ standard on the assumption that compiler
technology will catch up. My feeling is that for this particular issue
(Koenig lookup to resolve names which overload names in std::) there are two
points: (1) too many compilers still don't have the support to get this
right, and (2) there is a realistic possibility that the prohibition on
injecting the relevant names into std:: may be lifted.

Add to this the fact that the 2 compilers I have access to and use (MSVC,
mingw/gcc) both have serious issues in this area, and my judgement is that I
shouldn't fight this issue at the present time.

> | .... There's also the question of whether std::abs() is
> | available for all built-in types. The standard only mandates
> | std::abs(int) and std::abs(long) - while I can't see
> 
> `int' are designed to be C++'s primary choices for integer types.
> 'char' and variants are best thought of as character types and should
> not serve for airthmetics -- even if in Standardese they are called
> arithmetic types.  And they don't play very well with arithmetics.

Yes, but short is a possible (if unusual) choice. And a 64-bit type such as
"long long" or "__int64" or whatever the vendor chooses to call it is
potentially a very reasonable choice. And there's no abs() for them.

Paul.