Re: GCC viciously beaten by ICC in trig test!

[Ian Lance Taylor <ian at wasabisystems dot com>]

"Stephan T. Lavavej" <stl@caltech.edu> writes:

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

I see two reasons.  First, it's historical.  Second, C++ libraries are
often tied to the details of the compiler as the compiler evolves and
adds features.  Remember that the C++ standard is relatively new, and
that very few (I think only one) C++ compiler is fully standard
compliant.  The C++ library relies on the details of the C++ compiler
far more than the C library relies on the details of the C compiler.
Even today libstdc++-v3 uses at least one g++ extension--
attribute((strong)).  G++ has always been distributed with a C++
library--it used to be called libg++, then libstdc++, and now
libstdc++-v3.

Also, as others have noted, operating systems, not to mention POSIX
itself, have traditionally overloaded the ISO C header files with
additional declarations.  If gcc provided its own ISO C header files,
it still could not ignore those operating system extensions, because
real programs on those operating systems rely on them.  For example,
the glibc stdio.h defines functions like fmemopen, and those functions
are presumably implemented using internal details of FILE, which means
that fmemopen isn't going to interoperate with the gcc implementation
of getchar/fread, etc.  This leads you down the road of only using the
ISO C library for programs compiled with -ansi or -std=..., but then
we're back to the fact that relatively few programs can work in that
environment.

I don't think that any of these problems are insoluble, by the way.
But somebody would really have to word hard to develop a solution.

And first that person has to get buyin from the steering committee, of
course.

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

Since you mentioned Windows, I'll note that doing a Windows port of
the POSIX API (without using the broken Windows Posix services) is
quite a pain.  Starting along that path basically led to the cygwin
project.

Ian