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

[watzka@stat.uni-muenchen.de (Kurt Watzka)]

"William J. Leary Jr." <Bill_Leary@msn.com> writes:

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

What Kaz Kylheku is missing is the word "hosted environement". He knows
quite well that in a hosted environment, all the functions, macros,
type definitions, and objects described in the library clause may
be used, whereas in a freestanding environment (for example, an implementation
targeting your average toaster), and libary facilities available to
a program are implementation-defined.

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

Not so. The names are reserved in a hosted environment no matter what 
headers are included. This is what Kaz was trying to tell you.
"All identifiers with external linkage in any of the following (i.e
the library) subclauses including the future library directions
are always reserved for use as identifiers with external linkage" 
cannot be interpreted in a way that restricts the reservation to 
compilation units that include certain standard headers.

> In some cases a compiler will pay special attention to some of
>the routines (like strcpy) so it can inline them
>automagically.

I doubt that it is allowed to do so in a freestanding environenment
without explicitly stating that fact in its documentation.

> In all cases where I've seen this there's been a compiler
>switch to turn it off.

Again, the point is the difference between a freestanding environement
and a hosted environment. In a freestanding environment, the name and
type of the function called at program startup are implementation defined.
It may well be "void ToasterStart(float TimerSetting)". There are otherwise
no reserved external identifiers in a freestanding environment. This means
that you are indeed free to use names in your toaster control program 
that would be reserved identifiers in a program targeting a hosted
environment. 

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

This means that neither the compiler nor the linker is obliged in any
way to complain about the redefinition of functions from the standard
library, but the behaviour of such a program is still undefined. "It 
worked so far" is a _very_ weak proof of correctness, given that 
undefined behaviour may well be limited to Thursdays before Friday
the 13th in odd years.

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

This need not be true in a hosted environment. The compiler may well
inline calls to fputc(), or generate calls to __libc_term_FPUTC instead.

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

You wouldn't mind telling us which companies use or sell your products,
would you?

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

The possibility that the definition of the C programming language indeed
does permit what Kaz claims it to permit does obviously escape you. An
implementation of the C programming language is free to recognize calls
to functions from the standard C library as special cases and treat them
in a special way. If you think that this is not so, don't try to prove
your point with statements like "I tried it once and it looked as if it
worked on the implementation I was using at that time". Try to find some
text in the language definition that supports your point of view.

Kurt

-- 
| Kurt Watzka                             Phone : +49-89-2178-2781
| watzka@stat.uni-muenchen.de