Re: Which language pays most 17457 -- C++ vs. Java?

["William J. Leary Jr." <Bill_Leary@msn.com>]

 Kaz Kylheku wrote in message <67gvpa$m3t$1@brie.direct.ca>...
>The library is part of the language, you buffoon, the same way that basic
>words like  'air' and 'water' are part of English.


Not that I've ever noticed.  I frequently use C compilers to target embedded
systems.  We pretty much always discard the standard library and bring up
our own basic library for the features we actually need.  The standard
library pretty much is always hooked into the OS (or OS's)  the compiler is
targeting.  Since we're usually either on the iron, or on an RTOS the
standard stuff the standard library want's isn't usuall there.

>In C, the standard library functions have special status.
> First of all, their names are reserved external symbols.

Not usually.  Their "special status" comes from the fact that they get put
into the symbol table because you always include "stdio.h" or "stdlib.h" or
whatever.  In some cases a compiler will pay special attention to some of
the routines (like strcpy) so it can inline them
automagically.  In all cases where I've seen this there's been a compiler
switch to turn it off.

I've dumped the standard library lots of times and written new routines for
some of the standard features and never had a compiler or linker complain
about them.

> If any C program contains an external definition of an identifier that is
an external name
> reserved by the standard library, the behavior is undefined.

If you link in the standard library, you usually get a linker error, unless
the linker isn't too bright.  If you don't link in the library, it usually
just works as expected.  That is, your routine which replaced, say, fputc,
just gets linked in.

>Secondly, if you include a standard header, you may not redeclare any
symbol
>in that standard header, not even in a nested scope.

Done it several times.  Program started in DOS, so I needed the standard
libs for progress messages.  Switched to protected mode in high memory and
zapped DOS in low RAM for buffers.  Used my own fputc and so forth after
that.

> I'm not talking about optimization. I'm talking about recognition of
standard
> functions as thought they where primitives. The C standard permits an
> implementation to do that.

Yep, some compilers will do that.  Metaware, for example, will catch memcpy
and optimize it for the 80x86 REPT modifier.  It can be turned off with a
compile time switch, because it's NOT part of the C langauge but rather is
the compiler maker noticing a chance to get you better executing code by
implementing one of the standard library functions as if it were a language
primitave.

> ((.. omitted..))
> In C, it's like this: a strictly conforming program may not define its own
> strcmp() function with external linkage. If you want to write your own
strcmp,
> you would have to give it internal linkage using the static keyword:
static
> int strcmp(...) { ... }.  You are then forbidden from including the
<string.h>
> header in that translation unit.  The compiler is then required to
recognize
> that you have defined your own strcmp and no longer treat it as a built-in
> primitive.
>
>It works just fine in GCC, for instance.


I just realized here that you guys may be discussing two different things.

It sounds like one of you is arguing about the C language itself, and the
other is arguing about what makes up a standard C program.  The library
isn't part of the language.  Look at the syntax diagrams for the language.
There's no library features in there.  On the other hand, a standard C
program, one which is in compliance with the specs, does include that
library stuff.

    - Bill