Any C code are valid C++ code?

J

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.
 
R

Richard Bos

dandelion said:
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
 
D

dandelion

Richard Bos said:
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.
 
D

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top