Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: C++ and ANSI C
Message-ID: <1989May5.172754.20765@utzoo.uucp>
Organization: U of Toronto Zoology
References: <12005@paris.ics.uci.edu> <44100029@hcx2> <1989May4.001911.3382@utzoo.uucp> <3934@tekcrl.LABS.TEK.COM>
Date: Fri, 5 May 89 17:27:54 GMT

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