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.3 required=5.0 tests=BAYES_00, 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: fac41,a03ae7f4e53958e1 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,8775b19e3c68a5dc X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,a03ae7f4e53958e1 X-Google-Attributes: gid109fba,public X-Google-Thread: 114809,a03ae7f4e53958e1 X-Google-Attributes: gid114809,public X-Google-Thread: fa0ae,a03ae7f4e53958e1 X-Google-Attributes: gidfa0ae,public X-Google-Thread: 1014db,a03ae7f4e53958e1 X-Google-Attributes: gid1014db,public X-Google-Thread: 1094ba,a03ae7f4e53958e1 X-Google-Attributes: gid1094ba,public From: fred@genesis.demon.co.uk (Lawrence Kirby) Subject: Re: Which language pays most? Smalltalk, not C++ nor Java. Date: 1997/12/30 Message-ID: <883441372snz@genesis.demon.co.uk> X-Deja-AN: 311184644 References: <199712121931.LAA25389@sirius.infonex.com> <67iipp$ktj$1@darla.visi.com> <882756127snz@genesis.demon.co.uk> <34A14C27.57C0@min.net> <67rjb3$pfb$1@brie.direct.ca> <34A50CAA.54AA@netup.cl> <685mee$5d4$1@sparcserver.lrz-muenchen.de> <34A812F9.C169A703@its.cl> X-Mail2News-User: fred@genesis.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: genesis.demon.co.uk X-Trace: mail2news.demon.co.uk 883445595 14127 fred genesis.demon.co.uk Organization: none Reply-To: fred@genesis.demon.co.uk 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-30T00:00:00+00:00 List-Id: In article <34A812F9.C169A703@its.cl> gschwarz@its.cl "Guillermo Schwarz" writes: >Kurt Watzka wrote: > >> Guillermo Schwarz writes: >> >> >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. >> >> Well, looks as if there still is something to learn about C for you. >> The exact wording is "are reserved as identifiers with external >> linkage", but "reserved external name" looks close enough to me. >> > >It's nice to know C advances so fast I can't keep up to date with its >definition."Reserved as identifiers" is something meaningful to you? No, it doesn't out of context. Actually the wording above doesn't appear to be exact. The full sentence is (in 7.1.3) "- All identifiers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identifiers with external linkage" That means that if any of the following subclauses define an identifier (or name if you like) as having external linkage then you can't declare that identifier/name yourself with external linkage. If you do you get undefined behaviour which means anything can happen. It could be that the code compiles and does what you expected it to, that the code fails to compile, that the code compiles and does something completely different possibly even crashing during execution. This is reiterated to an extent in subclause 7.13 (Future library durections): "All external names described below are reserved no matter what headers are included by the program" One of the sections "below" is: "7.13.8 String handling Function names that begin with str, mem, or wcs and a lowercase letter (followed by any combination of digits, letters, and inderscore) may be added to the declarations in the header." >Can you reserve a name as a non indentifier? No, but that's not what it said. You're trying to take this out of context. >"with external linkage"? Those are too many words just to mean an extrernal >name. >The point is, at least when I studied the good and old K&R, it didn't mention > >"reserved as identifiers with external linkage", that for me means "don't >touch this, >or trick"... K&R2 doesn't define the language. It is an excellent book but there do seem to be a few things it doesn't cover properly. The index lists "reserved words" but that just seems to refer to keywords. Even though it was revised after the standard was released it seems to be based mainly on a draft standard. >The C guys modify their language each 3 months just when they >realize >something is missing. If you think it is funny, I think it is pretty messy. I don't know where you got that idea. The text I quoted was directly from the 1990 ISO standard. The text in the original 1989 ANSI standard is almost certainly the same - the only major thing that changed between the two was the section numbering. There have been 2 or maybe 3 changes to the standard since then but the scope of them is minor, mostly fixing errors and areas of confusion in the original. >In Smalltalk, there is USUALLY no need to change the language, but just the >need >to add new classes and methods to achieve what's needed. If you take K&R1 as a revision the C language seems to get revised in a significant way roughly every 10 years. That's not dissimilar to other languages (e.g. Ada-83,95 and Fortran 66,77,90) >> If memcpy is not defined as a function with external linkage, and >> if is not included, an implementation that does not >> sucessfully translate the program in question is at error. Did >> you actually _try_ it, and if yes, which implementation did >> "point out two different implementations"? > >You are right! I'm amazed. GNU gcc does implement memcpy directly (what is to >say thatmemcpy is inlined into the resulting exe, independently from how it >is defined >in the program). It is an optimisation choice the compiler is free to make for itself. This is possible because the language allows it to do anything it likes if you break the rules such as try to define your own memcpy() with external linkage. The compiler is allowed to "know" how standard library functions behave. >I would like to follow the only faith: smallTalk, so that my flesh doesn't >get rotten. > >How can somebody have a life, if the ANSI is changing the language so fast? It isn't. (As an aside ISO has controlled the C standard since 1990). >They think that by changing minor things they can keep C alive? >(I'm not meaning C is dead, but let Electronic Engineers do the drivers for >their >HW in C, but don't tell the rest of the world C is the right language because >it >is well implemented or something else wrong like that). No, the one thing that standardisation did was to effectively halt the development of the C language. This is a good thing for the reasons you imply. However C does still need to be allowed to develop occasionally. The 1989 language is showing its age in some areas e.g. lack of guaranteed support for 64 bit (or larger) integers. Being a lower level language than many it does have greater pressure on it to adapt to changing hardare capabilities. Still, the change rate is hardly excessive. >Maybe not too much people write their dirvers in Smalltalk because the >drivers >are very simple pieces of code. Drivers have no complex algorithms, they just > >need sti(), cli(). That's why drivers are made in C. That's why drivers were >made >in assembly. > >> The object model and design ideas behind C++ are completely different >> from Smalltalk. > >Objects have behavior and state in both languages.C doesn't have objects, nor >behavior, nor state. C has objects but it doesn't have all the OO paraphernalia that goes with them in a language like C++ (you could say it lacks the behaviour part). The purpose of an object in C is to store state. Maybe the OOP'ers have a more abstract view of what an object is. >C++ is backward compatible with C. It might be fair to say that C++ is mostly backwards compatible with C. However there is enough incompatibility to make it a bad idea to try to compile natural C code with a C++ compiler. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com -----------------------------------------