Boost logo

Boost :

From: Gabriel Dos Reis (Gabriel.Dos-Reis_at_[hidden])
Date: 2001-01-24 09:11:14

"Moore, Paul" <paul.moore_at_[hidden]> writes:

| 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,

That is not true. I've just tested the following with 2.95.2 (and I
believe it to work properly with the whole 2.95.x series.

    #include <iostream>

    namespace N { void f(int) { std::cout << "int\n"; } }

    void f(double) { std::cout << "double\n"; }

    void g()
      using N::f;

    int main ()


| > 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, ...]

I'am mainly concerned with your comment about std::abs. It was not
accurate. Whether other parts like <limits> are missing is another
issue and as I said earlier the whole implementation is a masquarade.

| 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.

That is also another other issue orthogonal to the not justified claim
that gcc-2.95.2 ignores using-declaration at function scope.


| > `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.

But it behaves in the same way as characters do.

| ... 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.

Yes, but a vendor who chooses to support long long or __int64 will
provide the accompaning functions if he thinks he want to support
those types as arithmetic types.

-- Gaby

Boost list run by bdawes at, gregod at, cpdaniel at, john at