This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GCC viciously beaten by ICC in trig test!


[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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]