Any C code are valid C++ code?

[john_bode]

Since C is a subset of C++, so any C code or C libraries (printf(),
scanf(), etc...)
are valid C++ code. Is that correct? so even though the whole program
is written in
C, but with .cpp extension, we still consider as C++ program?
Please advise. Thanks

C++ is not a proper superset of C, and there are some incompatibilities
between the two languages. Obviously, any C program that uses "new" or
"class" or any of the reserved words specific to C++ as an identifier
will not compile as C++. Some semantics are different (for example, in
C, sizeof('a') == sizeof (int), whereas in C++, sizeof('a') ==
sizeof(char)). In short, not every valid C program is a valid C++
program, and even those that are may exhibit different behavior.

The latest edition of Harbison & Steele's "C: A Reference Manual"
includes sections on C++ compatibility in every chapter.

 

[Richard Bos]

That qualifies as the most absurd reason i've heard to date for using any
particular language.

Absurd it may be, but I'd wager it's not all that uncommon. How many
projects are done in VWhatever/DotNet because it's the In Thing? Ditto,
a couple of years back, for Java.

Richard

 

[dandelion]

Absurd it may be, but I'd wager it's not all that uncommon. How many
projects are done in VWhatever/DotNet because it's the In Thing? Ditto,
a couple of years back, for Java.

Sadly enough (and out of my own expirience) I'd be unwilling to take that
bet, since you're probably right. However, I stand with my original remark.

 

[Mark McIntyre]

You mean C90 and C++, right? As far as I know, comments behave
identically in C99 and C++.

Yes.

 

[Dave Thompson]

xx

C lets you blur the distinction between ** and *[ ] and [ ][ ]
rather more, especially in function calls.

void foo(char a[2][2]) {
// do nothing
}

int main(void) {
char** a;
foo(a);
return 0;
}

will cause most C++ compilers to abort, as in C++ there's no possible
conversion from char** to *char[2].
A C compiler will typically complain but compile it anyway, perhaps since
there is often a practical way to perform the conversion.

Not really. On most (flat-addressed) machines you can 'convert' one
(data) pointer type to any other but it's still pointing to the wrong
thing. If you never use the result, as in your example, _that_ almost
always 'works' -- or can be made to by a cast. In neither language
does it work in the sense of being useful for anything.

On average and especially in the past C compilers have been more
permissive about 'ignoring' errors -- or rather, C++ compilers have
mostly deliberately been more restrictive. But this is not inherent in
either language; it is due more to the attitudes of the (groups of)
people who developed them early, leading to shared expectations, then
traditions (cue Tevye) that might reasonably be called cultures.

This may simply be a QOI issue or a case of getting overchummy with the
implementation. But I've come across this in real live production code
written by 3rd parties of great eminence.

If _this_ code was "live" -- i.e. actually executed and the result(s)
used -- I have trouble believing that. Depending on which sides write
and read, it should produce grossly wrong results or crash or at
"best" clobber memory that will likely break something else.

Now, I've seen lots of bogus code in production programs either not
used at all (cancelled or mistaken) or once used but obsoleted by
changes elsewhere, that people haven't fixed or removed because it
"isn't broken". Which isn't necessarily wrong; in some environments
there is a high cost to re-testing/validating _any_ production change,
no matter how small or "obvious"; cost and risk in deploying; and even
risk of breaking workarounds or adaptations. If the code is wrong but
not actually causing problems it can be worth living with it.

- David.Thompson1 at worldnet.att.net