This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: GCC viciously beaten by ICC in trig test!
- From: "Stephan T. Lavavej" <stl at caltech dot edu>
- To: "'GCC'" <gcc at gcc dot gnu dot org>
- Date: Mon, 15 Mar 2004 08:25:31 -0800
- Subject: RE: GCC viciously beaten by ICC in trig test!
- Reply-to: <stl at caltech dot edu>
[Ian Lance Taylor]
> The subset of programs which can work using only the ISO C
> standard functions is relatively small.
On the other hand, basically all programs use the ISO C standard functions.
Consistency in the standard functions would be nice.
And if this helps libstdc++, as Gabriel Dos Reis says, all the better.
> And the GNU project is already supporting a standard library
> --glibc.
Which, as far as I know, doesn't work on Windows.
As a user, I don't get why the C++ Standard Library gets to be in GCC, but
the C Standard Library doesn't. There are crazy extensions in C++ land too,
aren't there? If the situation with C++ were the same as the situation with
C, wouldn't everyone have to go forage for their own STL implementations?
Isn't that what people /did/ in the days of STLport and that nonsense?
And if this POSIX stuff causes problems, why can't two versions be
implemented - one pure 9899 1999, the other with all of the POSIX gunk that
users "expect".
I recently found that math.h (on GNU/Linux and MinGW, no less) was
prototyping some fool function named y1, which is not ISO. I didn't want
that gunk, but couldn't avoid it.
Quoth IRC...
<ithil> I say I can understand aversion to stupid standards, but for Pham's
sake, they're implementing /14882/
<ithil> The translation is none of the developers want to touch POSIX with a
ten-foot pole
<STL> Yeah, but /someone/ has to, ithil
<STL> It should be centralized to gcc, even though they don't want to do it
^_^
<ithil> write a patch ;p
<STL> Ha, now you're thinking like a gcc developer
Stephan T. Lavavej
http://nuwen.net