Any C code are valid C++ code?

[jrefactors]

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

[Mark McIntyre]

On 12 Dec 2004 15:22:18 -0500, in comp.lang.c , co****@panix.com (Greg
Comeau) wrote:

In article <41***************@plano.net>,
Charles Richmond <ri******@nospam.plano.net> wrote:

void cfunc()
{
/*--*//*--*/ printf("Hi C!!!\n"); /*--*//*--*/
}

In C, "Hi C!!!" would be printed. In C++, the line
should be a comment...

Not so.

True, but there are valid examples of where comments could operate
differently in C and C++.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.net> writes:

On 12 Dec 2004 15:22:18 -0500, in comp.lang.c , co****@panix.com (Greg
Comeau) wrote:

In article <41***************@plano.net>,
Charles Richmond <ri******@nospam.plano.net> wrote:

void cfunc()
{
/*--*//*--*/ printf("Hi C!!!\n"); /*--*//*--*/
}

In C, "Hi C!!!" would be printed. In C++, the line
should be a comment...

Not so.

True, but there are valid examples of where comments could operate
differently in C and C++.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dik T. Winter]

In article <cp**********@nntp1.jpl.nasa.gov> E.**************@jpl.nasa.gov writes:

Dik T. Winter wrote: ....

But making it compile with C++ is (in my opinion) *not* fixing it.

.... If you are uncomfortable with maintaining compatibility with C++,
that's a perfectly legitimate reason for not doing so.
But I think that most good C programmers are good C++
programmers as well and don't mind supporting customer's
legitimate requests for compatibility.

Perhaps I am not a good C programmer. I have had only two contacts
with C++. The first time when I had to implement a threads library
for C++ on a Sparc. The second time when I had to make a C++
program working on both SGI and Solaris, which was impossible with
identical code (the compilers supported different versions of C++).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

In article <cp**********@yin.interaccess.com> ga*****@interaccess.com writes:
....

Given that languages always evolve over time and add in new keyords, in some
sense it can never be said that a later version of any language is
a superset of an (or all) previous version(s) of that same language. This
is because some program written to the earlier spec may have used as an
identifier something which is now reserved to the implementation.

This is only true for languages where keywords are reserved identifiers
(as in C and Pascal). This is false for languages where keywords are
identifiers, but not reserved (as in Fortran), or were keywords are not
identifiers (Algol 60, Algol 68 (*)).
--
* But Algol 68 has the problem that new keywords may conflict with user
defined operators.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

In article <oq********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> writes:

On Sun, 12 Dec 2004 01:25:35 GMT, in comp.lang.c , "Dik T. Winter"
<Di********@cwi.nl> wrote:

There is *never* a practical way to perform the conversion.
Clearly there is, since the code actually works! Note that I'm not
speaking from an ISO C perspective.

So if the compiler passed 0 as an argument to foo you would think that
is a practical way to perform the conversion?

In both cases using 'a' will in general lead to strange behaviour of the
program.

Strange behaviour in this case including working as expected....

See the "using 'a'" bit? The only way to get it (possibly) working as
expected when you use a, is when foo passes it again to another function,
which either states the argument as "char a[2][2]" or something equivalent,
or passes it on again, or does not use it.

Consider the following:
#include <stdio.h>
void foo1(char *c) {
printf("%c\n", c);
}
void foo2(long *c) {
foo1(c);
}
int main(void) {
char *c = "hello";
foo2(c + 1);
return 0;
}
I know two systems where the program will *not* print 'e'.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

In article <jt********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> writes:

On Sun, 12 Dec 2004 01:56:03 GMT, in comp.lang.c , "Dik T. Winter"
<Di********@cwi.nl> wrote:

The difference between C++ and C is that in C++ conversions between
incompatible pointer types are not allowed. In C they are allowed,
but may produce garbage.
precisely my point. You might have some apparently-working C code which
simply would not compile under C++

Nope. You said: A C compiler will typically complain but compile it anyway, perhaps since
there is often a practical way to perform the conversion.

There is simply *no* practical way to perform the conversion. So compilers
simply do nothing (in this case), which works as long as you do not access
the thing as if it were a "pointer to pointer to char".

For instance, the following will not produce
what you think it should produce:

Sorry to be rude, but how do you know what I expect it to produce?

I have no idea. You started talking about a practical way to make the
conversion, so I thought you were thinking that there was a way to make
the converted pointer work as expected.

Now I am at a loss. What do you *mean* when you say "a practical way to
make the conversion"?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Greg Comeau]

In article <mb********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.net> wrote:

On 12 Dec 2004 15:22:18 -0500, in comp.lang.c , co****@panix.com (Greg
Comeau) wrote:

In article <41***************@plano.net>,
Charles Richmond <ri******@nospam.plano.net> wrote:

void cfunc()
{
/*--*//*--*/ printf("Hi C!!!\n"); /*--*//*--*/
}

In C, "Hi C!!!" would be printed. In C++, the line
should be a comment...

Not so.

True, but there are valid examples of where comments could operate
differently in C and C++.

Indeed. And yet, in Standard C++, the line above should not be
a comment, and furthermore ;) isn't.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Greg Comeau]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

On 12 Dec 2004 15:22:18 -0500, in comp.lang.c , co****@panix.com (Greg
Comeau) wrote:

In article <41***************@plano.net>,
Charles Richmond <ri******@nospam.plano.net> wrote:
void cfunc()
{
/*--*//*--*/ printf("Hi C!!!\n"); /*--*//*--*/
}

In C, "Hi C!!!" would be printed. In C++, the line
should be a comment...

Not so.

True, but there are valid examples of where comments could operate
differently in C and C++.

You mean C90 and C++, right?

Don't know what he means, but since // is C++ and C99,
then comment differences would be between C90 and C99, and
C90 and C++ mainly in areas with multi line expressions
involving mixtures of "old" and "new" comment styles.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Ron House]

Malcolm wrote:

"Chris Barts" <ch************@gmail.com> wrote

Since C is a subset of C++,

Wrong. A common notion that is completely wrong.

Partly wrong.

It's completely wrong. C is not a subset of C++. It makes as much sense
to say that "3 == 2" is not _completely_ wrong because 3 is pretty close
to 2. Thinking like this results in errors.

"C is a subset of C++" is completely wrong.

"C is almost a subset of C++" might be correct if everyone understands
"almost" suitably.

--
Ron House ho***@usq.edu.au
http://www.sci.usq.edu.au/staff/house

[Raymond Martineau]

On Sun, 12 Dec 2004 13:14:00 -0800, Charles Richmond <ri******@plano.net>
wrote:

Mark McIntyre wrote:

On 11 Dec 2004 19:35:13 -0500, in comp.lang.c , co****@panix.com (Greg
Comeau) wrote:
(snip long and hard to interpret compiler output stuff)

>I can't imagine any other C++ or C compiler acting differently in
>their strict modes too, at least to not even put out a warning.

I don't disagree, and indeed thats not what I said.

Did anyone post the following:

void cfunc()
{
/*--*//*--*/ printf("Hi C!!!\n"); /*--*//*--*/
}

In C, "Hi C!!!" would be printed. In C++, the line
should be a comment...

That's not the correct construct. When the "/*" comment delimiter is first
encountered, all text is read until the first "*/", including the end
delimiter. Unless there is some form of nested comments going on (which
is non-standard in either language), the "//" is not read at all.

The following function, however, demonstrates the lanugage differences:

int main()
{
printf("%d\n", 6 //*
+ 2); //**/ 2 );
}

Under C89, you get "3". Under C99 or C++, you get "8".

[Peter Nilsson]

Dik T. Winter wrote:

The difference between C++ and C is that in C++ conversions between
incompatible pointer types are not allowed. In C they are allowed,
but may produce garbage. For instance, the following will not
produce what you think it should produce:

#include <stdio.h>

void foo(char a[1][1]) {
printf("%c\n", a[0][0]);
return;
}

int main(void) {
char c, *b, **a;
a = &b; b = &c; c = 'd';
foo(a);
This line should produce a diagnostic for the simple assignment
constraint violation (C99 6.5.16.1p1.) return 0;
}

--
Peter

[dandelion]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:cp**********@newsg1.svr.pol.co.uk...

<snip>

I've had to write code that was to all intents and purposes C in C++,
because C++ was more in keeping with the image of the company.

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

[john_bode]

jr********@hotmail.com wrote:

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]

"dandelion" <da*******@meadow.net> wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:cp**********@newsg1.svr.pol.co.uk...

I've had to write code that was to all intents and purposes C in C++,
because C++ was more in keeping with the image of the company.

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]

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:41****************@news.individual.net...

"dandelion" <da*******@meadow.net> wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote in message
news:cp**********@newsg1.svr.pol.co.uk...

I've had to write code that was to all intents and purposes C in C++,
because C++ was more in keeping with the image of the company.

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.

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]

On Sun, 12 Dec 2004 23:35:09 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

True, but there are valid examples of where comments could operate
differently in C and C++.

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

Yes.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Mark McIntyre]

On Mon, 13 Dec 2004 00:43:57 GMT, in comp.lang.c , "Dik T. Winter"
<Di********@cwi.nl> wrote:

(snip example of passing one pointer type to a function expecting another)

I know two systems where the program will *not* print 'e'.

Me too, but this example is quite different to the topic under discussion.

I don't care enough about this to discuss it further. FWIW the code style I
mentioned earlier was in a working application, the array was used, and it
worked as expected. Go figure.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Dave Thompson]

xx
On Sat, 11 Dec 2004 16:11:59 +0000, Mark McIntyre
<ma**********@spamcop.net> wrote:

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