ech@pegasus.ATT.COM (Edward C Horvath) (05/04/89)
From article <2857@pegasus.ATT.COM>, by hansen@pegasus.ATT.COM (Tony L. Hansen): > The extern "language" linkage specification works both ways. Not only can > one specify that a function has been written in C, one can also specify that > a C++ function is to be linked just as a C function would be linked. For > example, > #include <stdio.h> > extern "C" void foo() { printf("foo\n"); } > ...the function "foo" will be known externally as > the unmangled name "foo". Both cfront 2.0 and Zortech's next C++ compiler > work this way. > By the way, the next version of Zortech's C++ compiler will also support the > extern "Pascal" > > linkage specification, in addition to the extern "C" and "C++" linkage > specifications. How nice; I'd hope that Apple's announced (shipping delta days after AT&T ships) MPW cfront will also support 'extern "pascal"': it'll make interfacing with the toolbox ever-so-much easier. It's less obvious how one will write more abstruse bits of code (like OS trap glue), but that's less than obvious in anything but assembler... =Ned Horvath=
henry@utzoo.uucp (Henry Spencer) (05/06/89)
In article <2858@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: >> extern "Pascal" >... will also support 'extern "pascal"'... Oh Lord, a new problem: are "Pascal" and "pascal" synonyms here? Only your implementor knows for sure... -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bright@Data-IO.COM (Walter Bright) (05/09/89)
In article <2858@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes:
<From article <2857@pegasus.ATT.COM<, by hansen@pegasus.ATT.COM (Tony L. Hansen):
<< By the way, the next version of Zortech's C++ compiler will also support the
<< extern "Pascal"
<< linkage specification, in addition to the extern "C" and "C++" linkage
<< specifications.
<How nice; I'd hope that Apple's announced (shipping delta days after AT&T
<ships) MPW cfront will also support 'extern "pascal"':
It's case sensitive, according to Bjarne's wishes. Thus, it's:
"C"
"C++"
"Pascal" // Capitalized 'cuz C and C++ are
Let's be consistent from the outset, to avoid silly annoyances.
I'll be so bold as to also propose:
"Fortran"
for those compilers so capable. Let's all avoid the mess that #pragma's
are sinking into.
This is a much better solution than the clumsy 'cdecl' and 'pascal'
keywords cluttering up things.keffer@blake.acs.washington.edu (Thomas Keffer) (05/09/89)
In article <1969@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: > >It's case sensitive, according to Bjarne's wishes. Thus, it's: > "C" > "C++" > "Pascal" // Capitalized 'cuz C and C++ are >Let's be consistent from the outset, to avoid silly annoyances. >I'll be so bold as to also propose: > "Fortran" >for those compilers so capable. Let's all avoid the mess that #pragma's >are sinking into. While we're at it, how about a standard suffix for C++ source code? I propose ".cxx" (as used by Oasys). Anything but CC's ".C" which cannot be distinguised from ".c" on MS-DOS machines. --- Dr. Thomas Keffer | Internet: keffer@sperm.ocean.washington.edu School of Oceanography | BITNET: keffer%sperm.ocean.washington.edu@UWAVM Univ. of Washington, WB-10 | uucp: uw-beaver!sperm.ocean.washington.edu!keffer Seattle, WA 98195 | Telemail: T.KEFFER/OMNET (206) 543-6455
jeffb@grace.cs.washington.edu (Jeff Bowden) (05/09/89)
In article <1950@blake.acs.washington.edu> keffer@blake.acs.washington.edu (Thomas Keffer) writes: >While we're at it, how about a standard suffix for C++ source code? I <propose ".cxx" (as used by Oasys). Anything but CC's ".C" which cannot >be distinguised from ".c" on MS-DOS machines. Why not go all the way and use ".c++" or ".C++" ? Seems like this would be most clear. Of course, I have no idea whether or not the fascist MS-DOS file system will allow "+" signs in filenames (but then again, I don't care). Personally I just use the ".c" extension and let my Makefile take care of the details (can you say "CC=g++"?) -- ``Say `lah vee.'''
hansen@pegasus.ATT.COM (Tony L. Hansen) (05/09/89)
< It's case sensitive, according to Bjarne's wishes. Thus, it's: < "C" < "C++" < "Pascal" // Capitalized 'cuz C and C++ are < Let's be consistent from the outset, to avoid silly annoyances. I'll be so < bold as to also propose: < "Fortran" < for those compilers so capable. Let's all avoid the mess that #pragma's < are sinking into. < < This is a much better solution than the clumsy 'cdecl' and 'pascal' < keywords cluttering up things. In Bjarne's latest draft C++ Reference Manual, he states: >> Where the name of a programming language is used to name a style of >> linkage in the string in a linkage-specification, it is recommended that >> the spelling be taken from the document defining that language. For >> example, Ada (not ADA) and FORTRAN (not Fortran). This means that "Pascal" is correct, as will be the names "Modula-2", "PL/I" (oh no!), "Eiffel", "BASIC" (double oh no!), "COBOL" (it keeps getting worse, doesn't it?), "Smalltalk-80", "Objective-C", and so on. Sorry Walter, you've been out voted. Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com
prc@erbe.se (Robert Claeson) (05/10/89)
In article <JEFFB.89May8141340@grace.cs.washington.edu>, jeffb@grace.cs.washington.edu (Jeff Bowden) writes: > In article <1950@blake.acs.washington.edu> keffer@blake.acs.washington.edu (Thomas Keffer) writes: > >While we're at it, how about a standard suffix for C++ source code? I > <propose ".cxx" (as used by Oasys). Anything but CC's ".C" which cannot > >be distinguised from ".c" on MS-DOS machines. > Why not go all the way and use ".c++" or ".C++"? > ... Of course, I have no idea whether or not the fascist MS-DOS > file system will allow "+" signs in filenames Neither DOS nor VMS allows "+" characters in file names, so why not do like Zortech, Oregon s/w and some other company whose name I forgot and use .cpp? -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
bright@Data-IO.COM (Walter Bright) (05/11/89)
In article <2865@pegasus.ATT.COM> hansen@pegasus.ATT.COM (Tony L. Hansen) writes:
<In Bjarne's latest draft C++ Reference Manual, he states:
I guess I must not have his latest draft.
<Sorry Walter, you've been out voted.
As usual, when Bjarne holds 51% of the voting stock!
:-) :-) :-) :-)jima@hplsla.HP.COM (Jim Adcock) (05/12/89)
< <In Bjarne's latest draft C++ Reference Manual, he states: < < I guess I must not have his latest draft. How would one get a copy of the latest draft? ------------ Does anyone have a pretty complete list of the "official" spellings of the major computer languages? .....I don't seem to be able to find a COBOL "Cobol? cobol? CoBoL?" reference anywhere... :-]
mat@mole-end.UUCP (Mark A Terribile) (05/12/89)
-----... how about a standard suffix for C++ source code? ... Anything but -----CC's ".C" which cannot be distinguised from ".c" on MS-DOS machines. --- Why not go all the way and use ".c++" or ".C++"? --- ... Of course, I have no idea whether or not the fascist MS-DOS --- file system will allow "+" signs in filenames - Neither DOS nor VMS allows "+" characters in file names, so why not do like - Zortech, Oregon s/w and some other company whose name I forgot and use .cpp? It seems to me that this whole matter is so inherently system dependent that it doesn't belong in the language specification. Mark T. -- (This man's opinions are his own.) From mole-end Mark Terribile
shankar@hpclscu.HP.COM (Shankar Unni) (05/14/89)
> In Bjarne's latest draft C++ Reference Manual, he states: > >> example, Ada (not ADA) and FORTRAN (not Fortran). Infinitesimal nit: "Fortran", not "FORTRAN". The latest version of Fortran seems to have renamed itself to this mixed-case version... Personally, I think that it should be case-insensitive. Many people spell Fortran, Pascal and Ada with different cases. Rather than make people memorize the "party-line" spellings, why not recognize them in any case? After all, "FORTRAN" is not really different from "Fortran".. (Oh, you were talking of FORTRAN-IV? :-)) ---- Shankar.
diamond@diamond.csl.sony.junet (Norman Diamond) (05/15/89)
In article <2865@pegasus.ATT.COM> hansen@pegasus.ATT.COM (Tony L. Hansen) writes: >This means that "Pascal" is correct, as will be the names "Modula-2", "PL/I" >(oh no!), "Eiffel", "BASIC" (double oh no!), "COBOL" (it keeps getting >worse, doesn't it?), "Smalltalk-80", "Objective-C", and so on. You forgot "APL\360". Or is that "APL??/360"? And how does one get the fonts right? -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-implementing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
cowan@marob.MASA.COM (John Cowan) (05/17/89)
In article <10252@socslgw.csl.sony.JUNET>, diamond@csl.sony.junet (Norman Diamond) writes: >You forgot "APL\360". Or is that "APL??/360"? And how does one get the >fonts right? Nope, that's "APL\\360". "\360" is probably an error, unless you have 9-bit (or larger) characters on your machine.
nevin1@cbnewsc.ATT.COM (nevin.j.liber) (05/17/89)
In article <1000011@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >Personally, I think that it should be case-insensitive. Many people spell >Fortran, Pascal and Ada with different cases. Rather than make people >memorize the "party-line" spellings, why not recognize them in any case? (IMHO) From a language point of view, it is more 'consistent' to have this case-sensitive. In the extern "language", "language" is technically a string constant, and it should obey the rules for string constants. If your particular compiler wishes to ignore case, so be it; it shouldn't be part of the language spec. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
cline@sunshine.ece.clarkson.edu (Marshall Cline) (05/25/89)
In article <833@cbnewsc.ATT.COM> nevin1@cbnewsc.ATT.COM (nevin.j.liber) writes: >In article <1000011@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >>Personally, I think that it should be case-insensitive. Many people spell >>Fortran, Pascal and Ada with different cases. Rather than make people >>memorize the "party-line" spellings, why not recognize them in any case? >(IMHO) From a language point of view, it is more 'consistent' to have >this case-sensitive. In the extern "language", "language" is >technically a string constant, and it should obey the rules for string >constants. If your particular compiler wishes to ignore case, so be >it; it shouldn't be part of the language spec. >NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751 I agree 100%. The same "wouldn't case insensitivity be nice" could be applied to keywords, but the language design is the language design. Consistency considerations draw you toward the "case sensitive" choice. (Even though Un*x isn't part of the discussion here, case sensitivity is the general rule there also, which increases the "consistency" magnetism). Marshall -- ________________________________________________________________ Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591
ech@pegasus.ATT.COM (Edward C Horvath) (05/25/89)
In article <1000011@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >Personally, I think that it should be case-insensitive. Many people spell >Fortran, Pascal and Ada with different cases. Rather than make people >memorize the "party-line" spellings, why not recognize them in any case? In article <833@cbnewsc.ATT.COM> nevin1@cbnewsc.ATT.COM (nevin.j.liber) writes: >(IMHO) From a language point of view, it is more 'consistent' to have >this case-sensitive... From article <CLINE.89May24161504@sunshine.ece.clarkson.edu>, by cline@sunshine.ece.clarkson.edu (Marshall Cline): > I agree 100%. The same "wouldn't case insensitivity be nice" could be > applied to keywords, but the language design is the language design. Oh, be real. Serve the user -- in this case the programmer. Consistency in support of the priest-class that can remember the convention is worthless. Yes, I am fully ordained. =Ned Horvath=
nevin1@cbnewsc.ATT.COM (nevin.j.liber) (06/03/89)
In article <2922@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: >In article <833@cbnewsc.ATT.COM> nevin1@ihlpb.ATT.COM (nevin.j.liber) writes: >>(IMHO) From a language point of view, it is more 'consistent' to have >>this case-sensitive... >Oh, be real. Serve the user -- in this case the programmer. Consistency >in support of the priest-class that can remember the convention is worthless. Using your own argument, to allow 'language' in extern "language" to be case-insensitive would become a convention concerning string literals which only the priest-class, of which, as you say, >Yes, I am fully ordained. :-), could remember, and therefore is useless. Inconsistency leads to a feeling of kludgyness about a language. Look at C: for at least the next ten years (assuming this doesn't get changed for the final ANS C standard, of course), initializer lists can have a comma after the last element while declarator lists cannot. It SHOULD (IMHO) be either both (which would be my choice if I were doing the designing) or neither; the way it is now, it seems 'wrong' and counter-intuitive. There are times when it is worth giving up consistency; however, this isn't one of them. In reality, what percentage of total code will contain the extern "language" construct? Very, very little. How many languages do you plan to incorporate in any given program? For most people, not more than one or two. To make string literals in this circumstance be case-insensitive would be far worse than having the user look up the spelling/casing of the language name once per project. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
flint@gistdev.UUCP (06/06/89)
The goal of consistency is to make it so that you know what to do in a particular case without having to spend time looking it up: you just learn the rule and thereafter you know what to type. The consistency being argued for here isn't consistent: (or at least it isn't consistent with the goal above :-) ) If you adopted Walter's idea that the case matters, but that the first letter of the language name should be capital and the rest of them not, THEN it would be consistent, and I would always know what to type when it came time to type in an extern "Fortran". However, that level of consistency has been "voted down" (too bad, IMHO). An approach that then says "the case in the language name matters, but we won't define any consistent rule on what case to use when" is completely inconsistent. I believe we can safely state that you aren't ever going to want to have: extern "Pascal" and extern "pascal" mean that you want to do something different in the two cases. God help us all if someone starts doing something like the above, so that "FORTRAN" refers to FORTRAN-77 linking while "Fortran" refers to newer versions because the language document changed: talk about priest-class rules. If the two versions above will never never ever mean different things, then the only possible reason for not recognizing them as the same construct is because you like to waste people's time with extra unnecssary compiles even though you knew exactly what the programmer wanted you to do. It appears to me that the ONLY way you can get back to a state where you do have "some" consistency is to say that you will consistently ignore the case in an extern. If that isn't consistent enough for you, argue for Walter's proposal, which is the only one we've seen yet that really is consistent. > nevin1@ihlpb.ATT.COM writes: >There are times when it is worth giving up consistency; however, this >isn't one of them. In reality, what percentage of total code will >contain the extern "language" construct? Very, very little. How many >languages do you plan to incorporate in any given program? You're wrong there, I believe. The programs of today are often built by reinventing the wheel whenever you need a new one: quite clearly, you don't start a new program very often intending to write it in 3 different languages. But more and more, what I'm seeing as a trend for tomorrow is increased inter-language linking, because you have thing X written in one language and thing Y in another, and you have to put them together now to move on: the existing applications are too big and have too much invested in them to start over just because you don't like the language they are in. (For example, there are large complex libraries of statistical analysis tools around in FORTRAN (or was that Fortran?) that people get stuck calling from C because they want to use user interface libraries written in C (for X), and they may have a relational database library accessible only with Pascal calls. The trend toward "everybody builds their applications on top of a set of software libraries they didn't write" instead of "everybody develops the entire thing from scratch" is going to force the need for more and more inter-language contact. Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 INTERNET: flint%gistdev@uxc.cso.uiuc.edu UUCP: {uunet,pur-ee,convex}!uiucuxc!gistdev!flint