ANSI C and C++

[Daniel E. Platt]

In article <3547 at intvax.UUCP>, novak at 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