henry@utzoo.uucp (Henry Spencer) (05/04/89)
In article <44100029@hcx2> daver@hcx2.SSD.HARRIS.COM writes: >From "Computerworld" (4/24/89, p. 31): > "... A key selling point of C++ is its relationship with the established C > language. It includes ANSI-standard C as a subset, as does Objective C, ..." > >Perhaps statements like the above cause the confusion... Quite likely, since they're not true. There are a couple of fundamental incompatibilities between C++ and C (ANSI or not), plus a number of minor ways in which ANSI C differs from C++ in areas where they overlap. Most of the latter will go away when Bjarne's crew gets the new official C++ reference manual out the door, but at the moment ANSI C is *not* a subset of C++, even if you ignore the big incompatibilities. Computerworld, as usual, basically doesn't know what it's talking about. To break the suspense, the two big incompatibilities are: 1. "extern foo();" means (so to speak) "extern foo(...);" in ANSI C and "extern foo(void);" in C++ 2. declaring a struct or union tag in C++ essentially does an implicit typedef on that identifier as well -- 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
danw@tekchips.LABS.TEK.COM (Daniel E. Wilson) (05/05/89)
In article <1989May4.001911.3382@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <44100029@hcx2> daver@hcx2.SSD.HARRIS.COM writes: > >From "Computerworld" (4/24/89, p. 31): > > "... A key selling point of C++ is its relationship with the established C > > language. It includes ANSI-standard C as a subset, as does Objective C, ..." > > To break the suspense, the two big incompatibilities are: > > 1. "extern foo();" means (so to speak) "extern foo(...);" in ANSI C and > "extern foo(void);" in C++ > > 2. declaring a struct or union tag in C++ essentially does an implicit > typedef on that identifier as well > -- Number 1 is incorrect since C++ uses '...' to indicate that the number and type of arguments is unknown. The void keyword in ANSI C indicates that the function takes no arguments. No arguments in the prototype in C++ means that there are no arguments. Number 2 is correct since the struct and union concepts in C++ are subsets of the class concept. The class concept requires that a class be a new data type. Dan Wilson
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/05/89)
In article <3934@tekcrl.LABS.TEK.COM> danw@tekchips.LABS.TEK.COM (Daniel E. Wilson) writes: >In article <1989May4.001911.3382@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: >> 1. "extern foo();" means (so to speak) "extern foo(...);" in ANSI C and >> "extern foo(void);" in C++ > Number 1 is incorrect since ... Your explanation was okay, but it didn't contradict Henry's point, which is correct. "extern foo();" in source code has the different meanings indicated in the two languages. Henry's "(so to speak)" was a warning that ANSI C doesn't actually support the C++ notation he used in his explanation. (Its similar-but-not-identical syntax for variable-argument functions has yet a different meaning.)
henry@utzoo.uucp (Henry Spencer) (05/06/89)
In article <3934@tekcrl.LABS.TEK.COM> danw@tekchips.LABS.TEK.COM (Daniel E. Wilson) writes: >> 1. "extern foo();" means (so to speak) "extern foo(...);" in ANSI C and >> "extern foo(void);" in C++ > > Number 1 is incorrect since C++ uses '...' to indicate that the number >and type of arguments is unknown. The void keyword in ANSI C indicates >that the function takes no arguments. No arguments in the prototype in >C++ means that there are no arguments. Uh, please read what I wrote: that's exactly what I said. Empty parens mean "arguments unknown" in ANSI C (with the "so to speak" because the usage of "..." in the above is not legal ANSI C) and "no arguments" in C++. Using the void keyword in this manner is legal in C++ -- it's a synonym for empty parens -- although it is officially described as an anachronism. >> 2. declaring a struct or union tag in C++ essentially does an implicit >> typedef on that identifier as well > > Number 2 is correct since the struct and union concepts in C++ >are subsets of the class concept. The class concept requires that >a class be a new data type. In retrospect, backward compatibility would have been much improved if struct and union had been made subsets of the class concept *except* for the implicit typedef. Then "class foo {" would still do the right thing but "struct foo {" would still have its old meaning. Too late now... -- 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
guy@auspex.auspex.com (Guy Harris) (05/06/89)
>> 1. "extern foo();" means (so to speak) "extern foo(...);" in ANSI C and >> "extern foo(void);" in C++ > > Number 1 is incorrect since C++ uses '...' to indicate that the number >and type of arguments is unknown. The void keyword in ANSI C indicates >that the function takes no arguments. No arguments in the prototype in >C++ means that there are no arguments. Uhh, that's what he *said*. ANSI C *also* uses "..." to indicate that the number and type of arguments (following a certain argument) is unknown. The "following a certain argument" is relevant - the December 7, 1988 draft indicates that the ellipsis must follow a comma, which follows an argument; this may be what the "so to speak" indicates. "The empty list in a function declarator that is not part of a function definition specifies that no information about the number or types of the parameters is supplied," so "extern foo();" is equivalent to what "extern foo (...);" would mean if it were allowed. "No arguments in the prototype in C++ means that there are no arguments" is equivalent to "'extern foo();; means ... 'extern foo (void);' in C++"; according to my copy of S ("S" being a construct whose meaning is determined by analogy to "K&R" :-)), under "15.3 Anachronisms", "The keyword 'void' may be used to indicate that a function takes no arguments, thus '(void)' is equivalent to '()'" (so to speak; presumably, () fprintf(stderr, "Doom, defeat, and despair!\n"); is not equivalent to (void) fprintf(stderr, "Doom, defeat, and despair!\n"); :-)).