Path: utzoo!attcan!uunet!bywater!scifi!ndla!platt From: platt@ndla.UUCP (Daniel E. Platt) Newsgroups: comp.lang.c Subject: Re: ANSI C and C++ Summary: 2 cents Message-ID: <315@ndla.UUCP> Date: 11 Jun 90 14:03:28 GMT References: <3547@intvax.UUCP> Lines: 56 In article <3547@intvax.UUCP>, novak@intvax.UUCP (James L. Novak) writes: > I apologise if I break any defined protocol re: comp.lang.c--I > am a new subscriber. > > > My question is: is C++ a superset of ANSI C such that any C++ > compiler will take ANSI C and spit out "standard" C (or binary)? POINT 1: I understand that for the most part, there is declaration compatibility except on one point. In ANSI C, a declaration with no arguments: double foo(); is interpreted to mean that foo may have an argument, but that it hasn't been specified to the compiler what the types are. If you want to specify that they function is to take NO arguments in ANSI C, you specify double foo(void); On the other hand, in C++, the specification double foo(); means that foo() has NO arguments (equivalent to 'double foo(void)' in ANSI C). POINT 2: C++ has generally been handled via a preprocessor that produces C code, with the expectation that a 'native' C++ compiler will follow. Some companies have been producing native C++ compilers not dependent on ATT's C++ translator. > I get conflicting answers, especially with regard to linking th > code to old C libraries (need to use "externc"). If you're using the translator based products, there shouldn't be a library incompatibility, since you're using the standard C compiler anyway. If you're using a native C++ compiler, you might have library problems. C++ also has its own libraries to worry about; but if you're not using the C++ standard 'streams.h' IO interface or other such, you probably don't need to worry about all that. > If this is true, can't we just all get C++ compilers? With the added advantages of object oriented programming, I'd tend to agree just on general prinicples. It enhances your options without restricting them. Dan