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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: 1014db,a03ae7f4e53958e1 X-Google-Attributes: gid1014db,public X-Google-Thread: fac41,a03ae7f4e53958e1 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,a03ae7f4e53958e1 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,8775b19e3c68a5dc X-Google-Attributes: gid103376,public X-Google-Thread: 114809,a03ae7f4e53958e1 X-Google-Attributes: gid114809,public X-Google-Thread: fa0ae,a03ae7f4e53958e1 X-Google-Attributes: gidfa0ae,public X-Google-Thread: 1094ba,a03ae7f4e53958e1 X-Google-Attributes: gid1094ba,public From: bill@cafe.net (Kaz Kylheku) Subject: Re: Which language pays most? Smalltalk, not C++ nor Java. Date: 1997/12/29 Message-ID: <688toi$j1r$1@brie.direct.ca>#1/1 X-Deja-AN: 311103653 References: <199712121931.LAA25389@sirius.infonex.com> <34A14C27.57C0@min.net> <67rjb3$pfb$1@brie.direct.ca> <34A50CAA.54AA@netup.cl> Organization: Internet Direct Reply-To: kaz@cafe.net 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-29T00:00:00+00:00 List-Id: In article <34A50CAA.54AA@netup.cl>, Guillermo Schwarz wrote: >Kaz Kylheku wrote: >> Although 'memcpy' is not a reserved keyword by any means, >> it is a reserved 'external name'. >It is the first time I see reserved external. The second time may come when you actually read the standard. >> A strictly conforming program may not define any external >> name that begins with 'mem' followed by any combination of letters, >> digits or underscores. >Ok. Define void memfoo() { } and see if it compiles. >It does. You clearly have no idea about what distinguishes a language definition from a language implementation. Of course the definition of memfoo compiles! But a future version of the C language may add memfoo to the standard library, at which point your program might not compile. An existing implementation may also define its own memfoo, knowing that a strictly conforming C program won't use such an identifier as an external name. >> Define memcpy, if you write such a static function, you must not >> include the header in >> the same translation unit, else undefined behavior results. >Wrong. The compiler points out two different implementations. >The executable can't be generated. That is a possible consequence of undefined behavior, yes. On many systems, however, you _can_ in fact write your own version of a standard function with external linkage. The result is that your program, and all libraries it is linked to, use the new function. That is another possible consequence of undefined behavior. If the standard required the implementation to fail to make an executable, it would not be undefined behavior. >> There is no such thing as ``overriding'' in C. Each external name must >> have exactly one definition if it is used anywhere in the program. >That's true. C is not object oriented. C++ is just an Smalltalk >wannabe. I wasn't talking about overriding methods in an ancestor class, but a physical overriding of external names at link time! This capability C++ does not have either; it has the One Definition Rule (ODR).