From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10a146,a03ae7f4e53958e1 X-Google-Attributes: gid10a146,public X-Google-Thread: fac41,a03ae7f4e53958e1 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,8775b19e3c68a5dc X-Google-Attributes: gid103376,public X-Google-Thread: 1094ba,a03ae7f4e53958e1 X-Google-Attributes: gid1094ba,public X-Google-Thread: 109fba,a03ae7f4e53958e1 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,a03ae7f4e53958e1 X-Google-Attributes: gid1014db,public X-Google-Thread: fa0ae,a03ae7f4e53958e1 X-Google-Attributes: gidfa0ae,public X-Google-Thread: 114809,a03ae7f4e53958e1 X-Google-Attributes: gid114809,public From: "William J. Leary Jr." Subject: Re: Which language pays most 17457 -- C++ vs. Java? Date: 1997/12/20 Message-ID: #1/1 X-Deja-AN: 308932109 References: <199712121931.LAA25389@sirius.infonex.com> <67bjnv$j35$1@brie.direct.ca> <349B0417.D4DB6A30@its.cl> <67gvpa$m3t$1@brie.direct.ca> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: Paralyn Associates Newsgroups: comp.lang.fortran,comp.lang.c,comp.lang.c++,comp.lang.eiffel,comp.lang.java.programmer,comp.lang.smalltalk,comp.lang.perl.misc,comp.lang.ada,comp.edu Date: 1997-12-20T00:00:00+00:00 List-Id: 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 > 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