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

[Victor Bazarov]

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

Since C is a subset of C++ [...]

Wrong premise. Wrong conclusion. The answer to your subj is "no".

[gianguz]

The answer is 'no' in general.For example one of the basic difference
(even if you create a simple hello world program and compile it under
with a C and a C++ compiler) between C and C++ relies almost in the
name mangling mechanism. C++ uses an extended decoration method to give
the linker indications about the name resolutions.
That tecnique is not compatible with C declaration naming.
This is the reason why you have to specify extern "C" {... } around C
code to ensure
compatibility.
Obviously there are other things that makes the two language very far
even so similar! ;)

Gianguglielmo

[Jonathan Bartlett]

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

Since C is a subset of C++

C is not a subset of C++. C++ has some incompatible changes from C.
However, they are compatible enough that a lot of code runs in both.

Some incompatibilities includes:

* different linking mechanisms (this is workaroundable w/ extern C)
* different interpretation of multidimensional arrays
* many C programs include typedefs and define which override C++
keywords, and therefore aren't allowed in C++ (typedef int bool; for
example)

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017

[Alex Vinokur]

"Jonathan Bartlett" <jo*****@eskimo.com> wrote in message news:41********@news.tulsaconnect.com...

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

Since C is a subset of C++
C is not a subset of C++. C++ has some incompatible changes from C.
However, they are compatible enough that a lot of code runs in both.

Some incompatibilities includes:

[snip]
* different interpretation of multidimensional arrays

What is the difference?

[snip]

--
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

[Chris Barts]

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

Since C is a subset of C++,
Wrong. A common notion that is completely wrong.
so any C code or C libraries (printf(), scanf(), etc...)
are valid C++ code.
Not true. For example, the following valid C program is not valid C++:

#include <stdlib.h>

int main(void)
{
/* new is a reserved word in C++ */
char new, *buf;
/* Implicit conversion from void* to char* not valid in C++ */
buf = malloc(1024);
free(buf);
return 0;
}

It is the case that you can use the C standard library functions in C++
code. However, it is rarely the best way to accomplish the task.
Is that correct? so even though the whole program
is written in
C, but with .cpp extension, we still consider as C++ program?

You can consider it a C++ program when it conforms to the relevant
standards. Writing in C is not a good way to conform to those standards.

[Chris Torek]

In article <11**********************@c13g2000cwb.googlegroups .com>
<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?

No.

Compile the following program as a C program and run it. Then,
compile it as a C++ program and run that. Observe the different
output.

#include <stdio.h>

struct A { char c[1000]; };

int main(void) {
struct B { struct A { char c[1]; } a; char c[1]; };

printf("sizeof(struct A): %lu\n", (unsigned long)sizeof(struct A));
return 0;
}

This is, of course, a carefully-constructed example -- but real C
programs really do fail to work when compiled as C++ programs,
sometimes, because of small but significant semantic changes.

(Exercise: *why* is the output different?)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Mark McIntyre]

On Fri, 10 Dec 2004 20:42:03 +0200, in comp.lang.c , "Alex Vinokur"
<al****@big-foot.com> wrote:

"Jonathan Bartlett" <jo*****@eskimo.com> wrote

* different interpretation of multidimensional arrays

What is the difference?

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

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

[Jonathan Bartlett]

* different interpretation of multidimensional arrays

What is the difference?

Apparently I was incorrect. I had thought that C allocated them in a
static block while C++ allocated them as arrays of arrays, but a little
experimentation showed my ideas to be faulty.

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017

[jcoffin]

C is not a subset of C++.

The C++ standard does require support for the C library, but with a few
changes in how that support must be provided (e.g. more restrictions on
which parts can be implemented as macros).

There are other differences, some of which have been pointed out
already, but I'll add yet another bit of code to demonstrate a
difference I haven't seen pointed out yet:

char x[sizeof('a')-1];

All properly-functioning C++ compilers are guaranteed to reject this.
In theory a C compiler could reject it as well, but I've never seen one
that did.

From the opposite viewpoint, most reasonably-written C can be converted

to C++ with only minimal changes, perhaps the most obvious of which is
that in well-written C, there should not be an explicit cast on the
value returned by malloc, while C++ requires one -- though well-written
C++ will rarely use malloc at all.

--
Later,
Jerry.

The universe is a figment of its own imagination.
--
Later,
Jerry.

The universe is a figment of its own imagination.

[Victor Bazarov]

Jonathan Bartlett wrote:

* different interpretation of multidimensional arrays

What is the difference?

Apparently I was incorrect. I had thought that C allocated them in a
static block while C++ allocated them as arrays of arrays, but a little
experimentation showed my ideas to be faulty.

No, your ideas are correct. The incorrect part is that you think that
there is a difference between "static block" and "array of arrays".

In fact, in both languages a multidimensional array is an array of arrays.
It is also true that in both languages all elements of a multidimensional
array sit next to each other, making it what you call "a static block".

V

[E. Robert Tisdale]

Victor Bazarov wrote:

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

Since C is a subset of C++ [...]

Wrong premise. Wrong conclusion. The answer to your subj is "no".

Practically speaking, C is a subset of C++.
There are few exceptions.
Each new C++ standard attempts to subsume each new C standard.

[Richard Tobin]

In article <cp**********@nntp1.jpl.nasa.gov>,
E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

Practically speaking, C is a subset of C++.

Practically speaking, I've found that's not the case. On several
occasions, people have mailed me to ask why one of my C programs
doesn't compile, and the answer has turned out to be that they were
trying to compile it as C++.

I have also had to conditionalize a .h file on defined(__cplusplus) to
allow it to be used in C++ programs without breaking backward
compatibility for existing (C) users.

-- Richard

[Default User]

Mark McIntyre wrote:

On Fri, 10 Dec 2004 20:42:03 +0200, in comp.lang.c , "Alex Vinokur"
<al****@big-foot.com> wrote:

"Jonathan Bartlett" <jo*****@eskimo.com> wrote

* different interpretation of multidimensional arrays

What is the difference?

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

Eh, what? Could you explain?


Brian

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Victor Bazarov wrote:

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

Since C is a subset of C++ [...]

Wrong premise. Wrong conclusion. The answer to your subj is "no".

Practically speaking, C is a subset of C++.
There are few exceptions.
Each new C++ standard attempts to subsume each new C standard.

The number of C constructs that either are invalid C++ or are valid
C++ with different semantics is small.

The number of real-world well-written C programs that use those
constructs is much larger.

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

[E. Robert Tisdale]

Richard Tobin wrote:

E. Robert Tisdale wrote:

Practically speaking, C is a subset of C++.

Practically speaking, I've found that's not the case.
On several occasions, people have mailed me to ask
why one of my C programs doesn't compile,
and the answer has turned out to be that
they were trying to compile it as C++.

I have also had to conditionalize a .h file on defined(__cplusplus)
to allow it to be used in C++ programs
without breaking backward compatibility for existing (C) users.

From which I conclude that
it isn't very difficult at all for you
to ensure that your C code will compile as C++ code
and perform as expected.

[Richard Tobin]

In article <cp**********@nntp1.jpl.nasa.gov>,
E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

From which I conclude that
it isn't very difficult at all for you
to ensure that your C code will compile as C++ code
and perform as expected.

Possibly not, but I have no incentive to do so.

-- Richard

[E. Robert Tisdale]

Richard Tobin wrote:

E. Robert Tisdale wrote:

From which I conclude that
it isn't very difficult at all for you
to ensure that your C code will compile as C++ code
and perform as expected.

Possibly not, but I have no incentive to do so.

Evidently, you don't think of the people who
"have mailed me to ask why one of my C programs doesn't compile"
as customers or employers.

[Dik T. Winter]

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

Richard Tobin wrote:

E. Robert Tisdale wrote:

From which I conclude that
it isn't very difficult at all for you
to ensure that your C code will compile as C++ code
and perform as expected.

Possibly not, but I have no incentive to do so.

Evidently, you don't think of the people who
"have mailed me to ask why one of my C programs doesn't compile"
as customers or employers.

Probably you have not thought that the C programs involved possibly
were freeware? Obviously, if the person complaining is a customer
or an employer, there is pretty good incentive to make changes.
When somebody complains about a program I put out for free, I will
simply let it go if it is some incompatibility. Only when a (good)
suggestion for change is involved am I inclined to modify. Why
should I put in my free time in changing things that work for me as
I want?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Victor Bazarov]

"Dik T. Winter" <Di********@cwi.nl> wrote...

[...] Why
should I put in my free time in changing things that work for me as
I want?

Why did you feel compelled to publish it in the first place? Can
the same reason apply to compel you to fix it? If not, was it the
_real_ reason you published your code? You don't have to answer.

V

[E. Robert Tisdale]

Dik T. Winter wrote:

E. Robert Tisdale writes:

> Richard Tobin wrote:

> > E. Robert Tisdale wrote:
> >>From which I conclude that
> >>it isn't very difficult at all for you
> >>to ensure that your C code will compile as C++ code
> >>and perform as expected.
> >
> > Possibly not, but I have no incentive to do so.

>
> Evidently, you don't think of the people who
> "have mailed me to ask why one of my C programs doesn't compile"
> as customers or employers.

Probably you have not thought that the C programs involved possibly
were freeware? Obviously, if the person complaining is a customer
or an employer, there is pretty good incentive to make changes.
When somebody complains about a program I put out for free, I will
simply let it go if it is some incompatibility. Only when a (good)
suggestion for change is involved am I inclined to modify. Why
should I put in my free time in changing things that work for me as
I want?

Apparently, it's a question of pride versus professionalism.

[Herbert Rosenau]

On Fri, 10 Dec 2004 21:56:42 UTC, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

Victor Bazarov wrote:

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

Since C is a subset of C++ [...]

Wrong premise. Wrong conclusion. The answer to your subj is "no".

Practically speaking, C is a subset of C++.
There are few exceptions.
Each new C++ standard attempts to subsume each new C standard.

Twitsdale proves again that he does not even know what C is. You
should ignore that Twit completely.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Malcolm]

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

Since C is a subset of C++,

Wrong. A common notion that is completely wrong.

Partly wrong. C++ was designed as a superset of C, but in order to avoid
uglification it was accepted that some C scripts would break when compiled
under C++. In fact it turns out that the majority of real C scripts will so
break, unless written with the deliberate intention of compiling under both
langages. This is not difficult to achieve, but does require some care.

[Richard Tobin]

In article <cp**********@nntp1.jpl.nasa.gov>,
E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:

Possibly not, but I have no incentive to do so.

Evidently, you don't think of the people who
"have mailed me to ask why one of my C programs doesn't compile"
as customers or employers.

Some of them were customers or potential customers. And of course
I did answer their question: I told them to use a C compiler.

Perhaps it is different for you, but I have the good fortune to be in
a position where just because someone is an employer or customer, I
don't have to abandon my own judgment when answering their questions.

-- Richard

[Mark McIntyre]

On Fri, 10 Dec 2004 23:20:33 GMT, in comp.lang.c , "Default User"
<fi********@boeing.com.invalid> wrote:

Mark McIntyre wrote:

On Fri, 10 Dec 2004 20:42:03 +0200, in comp.lang.c , "Alex Vinokur"
<al****@big-foot.com> wrote:

>"Jonathan Bartlett" <jo*****@eskimo.com> wrote
>> * different interpretation of multidimensional arrays

> What is the difference?

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

Eh, what? Could you explain?

This code
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.

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

[Malcolm]

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote

Perhaps it is different for you, but I have the good fortune to be in
a position where just because someone is an employer or customer, I
don't have to abandon my own judgment when answering their questions.

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.

[Joona I Palaste]

Mark McIntyre <ma**********@spamcop.net> scribbled the following
on comp.lang.c:

On Fri, 10 Dec 2004 23:20:33 GMT, in comp.lang.c , "Default User"
<fi********@boeing.com.invalid> wrote:

Mark McIntyre wrote:

On Fri, 10 Dec 2004 20:42:03 +0200, in comp.lang.c , "Alex Vinokur"
<al****@big-foot.com> wrote:
>"Jonathan Bartlett" <jo*****@eskimo.com> wrote
>> * different interpretation of multidimensional arrays

> What is the difference?

C lets you blur the distinction between ** and *[ ] and [ ][ ]
rather more, especially in function calls.
Eh, what? Could you explain?

This code
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. 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.

I don't understand. Although the C standard says that the type char[2]
is assignable to the type char *, it also says that the type char[2][2]
is definitely *not* assignable to the type char **.
When you indirect into a char[2][2] or a char(*)[2], you expect to find
two bytes of storage right there. However, when you indirect into a
char **, you expect to find a pointer, which then points to another
byte, which might or might not be storage.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen

[Kenny McCormack]

In article <9K********************@onewest.net>,
Chris Barts <ch************@gmail.com> wrote:

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

Since C is a subset of C++,

Wrong. A common notion that is completely wrong.

so any C code or C libraries (printf(), scanf(), etc...)
are valid C++ code.

Not true. For example, the following valid C program is not valid C++:

#include <stdlib.h>

int main(void)
{
/* new is a reserved word in C++ */
char new, *buf;

Leaving aside the malloc issues, I'd like to comment on the "new is
a reserved word" issue, in the context of languages in general.

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.

I know that C has some features designed to minimize this, such as
reserving certain ranges of words (e.g., str*), features that are not found
in other languages, but still the problem persists. As they say, this is
why they pay us the big bucks...

[Christian Bau]

In article <9atud.479764$wV.300818@attbi_s54>,
"Victor Bazarov" <v.********@comAcast.net> wrote:

"Dik T. Winter" <Di********@cwi.nl> wrote...

[...] Why
should I put in my free time in changing things that work for me as
I want?

Why did you feel compelled to publish it in the first place? Can
the same reason apply to compel you to fix it? If not, was it the
_real_ reason you published your code? You don't have to answer.

If I write C code that I didn't intentionally make C++ compatible, then
there is always a chance that for some minor reason the code won't work
if compiled as a C++ program.

However, if you take my C source code, compile it using a C++ compiler,
and you are not capable of fixing whatever minor problems come up, then
perhaps it is dangerous letting you loose on that code.

[Mark McIntyre]

On 11 Dec 2004 18:20:05 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:

Mark McIntyre <ma**********@spamcop.net> scribbled the following
on comp.lang.c:
(snip pretty contrived example of difference between C and C+ compiler)

I don't understand. Although the C standard says that the type char[2]
is assignable to the type char *, it also says that the type char[2][2]
is definitely *not* assignable to the type char **.
Yeah, maybe. But no C compiler I've encountered will reject this code,
while every C++ one will. Like I said, QOI, or what? I belive you're right,
but the fact is, C code that compiles /and runs just fine on multiple
implementations/ won't even compile under C++.
When you indirect into a char[2][2] or a char(*)[2], you expect to find
two bytes of storage right there. However, when you indirect into a
char **, you expect to find a pointer, which then points to another
byte, which might or might not be storage.

Could be, Zaphod.

But remind me, does an array degenerate to a pointer under certain
circumstances, and is a pointer to x roughly the same as the address of a
block of type x? Or not? Or ....My heads hurt.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Greg Comeau]

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

On 11 Dec 2004 18:20:05 GMT, in comp.lang.c , Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:

Mark McIntyre <ma**********@spamcop.net> scribbled the following
on comp.lang.c:

(snip pretty contrived example of difference between C and C+ compiler)

I don't understand. Although the C standard says that the type char[2]
is assignable to the type char *, it also says that the type char[2][2]
is definitely *not* assignable to the type char **.

Yeah, maybe. But no C compiler I've encountered will reject this code,
while every C++ one will. Like I said, QOI, or what? I belive you're right,
but the fact is, C code that compiles /and runs just fine on multiple
implementations/ won't even compile under C++.

Note the MODEs lines:

G:\tmp>como fooa.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:non-strict warnings microsoft C++

"fooa.cpp", line 10: error: argument of type "char **" is incompatible with
parameter of type "char (*)[2]"
foo(a);
^

"fooa.cpp", line 10: warning: variable "a" is used before its value is set
foo(a);
^

1 error detected in the compilation of "fooa.cpp".

G:\tmp>como --A fooa.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C++

"fooa.cpp", line 10: error: argument of type "char **" is incompatible with
parameter of type "char (*)[2]"
foo(a);
^

"fooa.cpp", line 10: warning: variable "a" is used before its value is set
foo(a);
^

1 error detected in the compilation of "fooa.cpp".
"fooa.cpp", line 10: error: argument of type "char **" is incompatible with
parameter of type "char (*)[2]"
foo(a);
^

"fooa.cpp", line 10: warning: variable "a" is used before its value is set
foo(a);
^

1 error detected in the compilation of "fooa.cpp".

G:\tmp>como --c fooa.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:non-strict warnings microsoft C90

"fooa.cpp", line 10: warning: argument of type "char **" is incompatible with
parameter of type "char (*)[2]"
foo(a);
^

"fooa.cpp", line 10: warning: variable "a" is used before its value is set
foo(a);
^
G:\tmp>como --c --A fooa.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C90

"fooa.cpp", line 2: error: expected an expression
// do nothing
^

"fooa.cpp", line 5: warning: parsing restarts here after previous syntax error
}
^

"fooa.cpp", line 5: error: expected a ";"
}
^

"fooa.cpp", line 10: error: argument of type "char **" is incompatible with
parameter of type "char (*)[2]"
foo(a);
^

"fooa.cpp", line 10: warning: variable "a" is used before its value is set
foo(a);
^

3 errors detected in the compilation of "fooa.cpp".

G:\tmp>como --c99 fooa.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:non-strict warnings microsoft C99

"fooa.cpp", line 10: warning: argument of type "char **" is incompatible with
parameter of type "char (*)[2]"
foo(a);
^

"fooa.cpp", line 10: warning: variable "a" is used before its value is set
foo(a);
^
G:\tmp>como --c99 --A fooa.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C99

"fooa.cpp", line 10: error: argument of type "char **" is incompatible with
parameter of type "char (*)[2]"
foo(a);
^

"fooa.cpp", line 10: warning: variable "a" is used before its value is set
foo(a);
^

1 error detected in the compilation of "fooa.cpp".

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

[Dik T. Winter]

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

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.

There is *never* a practical way to perform the conversion. What is
happening is that you are invoking an implicit cast between two
incompatible pointer types. A C compiler will also compile:
void foo(double *a) {return; }
int main(void) { int *a; foo(a); return 0: }
which makes just as much sense.

In both cases using 'a' will in general lead to strange behaviour of the
program.
--
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 <9atud.479764$wV.300818@attbi_s54> "Victor Bazarov" <v.********@comAcast.net> writes:

"Dik T. Winter" <Di********@cwi.nl> wrote...

[...] Why
should I put in my free time in changing things that work for me as
I want?

Why did you feel compelled to publish it in the first place? Can
the same reason apply to compel you to fix it? If not, was it the
_real_ reason you published your code? You don't have to answer.

People around me thought the package useful, so I thought it might be
useful to others as well and I put it in my ftp-directory. And I have
been fixing bugs that were reported, even when the bugs only were present
on systems to which I have no access (and happily people that reported
bugs in most cases also provided fixes). But making it compile with C++
is (in my opinion) *not* fixing it.

And apparently it is still thought useful after all those years. It is
part of one of the Linux distributions.
--
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 <l7********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> writes:

Yeah, maybe. But no C compiler I've encountered will reject this code,
while every C++ one will. Like I said, QOI, or what? I belive you're right,
but the fact is, C code that compiles /and runs just fine on multiple
implementations/ won't even compile under C++.

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);
return 0;
}
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[E. Robert Tisdale]

Dik T. Winter wrote:

Victor Bazarov writes:

Dik T. Winter wrote:

[...] Why should I put in my free time
in changing things that work for me as I want?

Why did you feel compelled to publish it in the first place? Can
the same reason apply to compel you to fix it? If not, was it the
_real_ reason you published your code? You don't have to answer.

People around me thought the package useful, so I thought [that]
it might be useful to others as well and I put it in my ftp-directory.
And I have been fixing bugs that were reported,
even when the bugs only were present on systems to which I have no access
(and happily people that reported bugs in most cases also provided fixes).
But making it compile with C++ is (in my opinion) *not* fixing it.

And apparently it is still thought useful after all those years.
It is part of one of the Linux distributions.

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.

[Greg Comeau]

In article <I8********@cwi.nl>, Dik T. Winter <Di********@cwi.nl> wrote:

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

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.

There is *never* a practical way to perform the conversion. What is
happening is that you are invoking an implicit cast between two
incompatible pointer types. A C compiler will also compile:
void foo(double *a) {return; }
int main(void) { int *a; foo(a); return 0: }
which makes just as much sense.

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

G:\tmp>como --c90 --A incompat.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C90

"incompat.cpp", line 2: error: argument of type "int *" is incompatible with
parameter of type "double *"
int main(void) { int *a; foo(a); return 0; }
^

"incompat.cpp", line 2: warning: variable "a" is used before its value is set
int main(void) { int *a; foo(a); return 0; }
^

1 error detected in the compilation of "incompat.cpp".

G:\tmp>como --c99 --A incompat.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C99

"incompat.cpp", line 2: error: argument of type "int *" is incompatible with
parameter of type "double *"
int main(void) { int *a; foo(a); return 0; }
^

"incompat.cpp", line 2: warning: variable "a" is used before its value is set
int main(void) { int *a; foo(a); return 0; }
^

1 error detected in the compilation of "incompat.cpp".
--
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 <I8*******@cwi.nl>, Dik T. Winter <Di********@cwi.nl> wrote:

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

Yeah, maybe. But no C compiler I've encountered will reject this code,
while every C++ one will. Like I said, QOI, or what? I belive you're right,
but the fact is, C code that compiles /and runs just fine on multiple
implementations/ won't even compile under C++.

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);
return 0;
}

G:\tmp>como --c90 --A notallowed.c
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C90

"notallowed.c", line 11: error: argument of type "char **" is incompatible
with parameter of type "char (*)[1]"
foo(a);
^

1 error detected in the compilation of "notallowed.c".

G:\tmp>como --c99 --A notallowed.c
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C99

"notallowed.c", line 11: error: argument of type "char **" is incompatible
with parameter of type "char (*)[1]"
foo(a);
^

1 error detected in the compilation of "notallowed.c".
--
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?

[Chris Barts]

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. C++ was designed as a superset of C, but in order to avoid
uglification it was accepted that some C scripts would break when compiled
under C++. In fact it turns out that the majority of real C scripts will so
break, unless written with the deliberate intention of compiling under both
langages. This is not difficult to achieve, but does require some care.

Mathematically, it's completely wrong: A subset must either be identical
to the set it is a subset of or it must lack one or more elements (iff
it is a strict subset). (Hey, if you didn't want nitpicking, why are you
in c.l.c?)

So, does derision still fit in with uglification? ;)

[Chris Barts]

Kenny McCormack wrote:

In article <9K********************@onewest.net>,
Chris Barts <ch************@gmail.com> wrote:

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

so any C code or C libraries (printf(), scanf(), etc...)
are valid C++ code.
Not true. For example, the following valid C program is not valid C++:

#include <stdlib.h>

int main(void)
{
/* new is a reserved word in C++ */
char new, *buf;

Leaving aside the malloc issues, I'd like to comment on the "new is
a reserved word" issue, in the context of languages in general.

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 true. I knew it was a somewhat vacuous example when I posted it,
which is why I immediately followed it up with a more substantive one.
My point was that there have been changes great and small to the parts
of C++ some think come direct and unmodified from C.

I know that C has some features designed to minimize this, such as
reserving certain ranges of words (e.g., str*), features that are not found
in other languages, but still the problem persists. As they say, this is
why they pay us the big bucks...

Again, true. C99 isn't a true superset of C89, if you want to be
pedantic, because of things like implicit int being cleaned from the
language, among other things. But C++ is even less of a superset of C99
than C99 is of C89.

[Malcolm]

"Kenny McCormack" <ga*****@yin.interaccess.com> wrote

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.

The C++ folks could have made "@friend" or some similar illegal C construct
the keyword in their language, and allowed continued use of "friend" as an
identifier. Maybe this would have been a good idea.

[Mark McIntyre]

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.

--
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 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++
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?

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

[Flash Gordon]

On Sat, 11 Dec 2004 18:02:20 -0800
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

<snip>

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.

I have known many good C programmers who have never written a single C++
class, let alone a complete C++ program and have no knowledge of OOP.

If a customer only had access to a C++ compiler then it *might* be valid
to consider making a C program compatible with C++, but in general they
should use the type of compiler the program was designed for.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Greg Comeau]

In article <7p********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.net> 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.

Oh, I agree it's not what you said. You offered your facts
and opinions, I just continued in the same vein.
--
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?

[robert.thorpe]

I have converted C code to C++ in practice. It is not simple and there
are many problems caused by tiny differences. So, I would say
practically speaking C is not a subset of C++.

If the author of the code writes it to work as both C and C++ then this
is not a problem.

[robert.thorpe]

You are right, there are very good reasons for writing in a well
defined language.
Attempting to write something of significant size that works as both C
and C++ is not simple. It ought not to be attempted unless those doing
it know exactly what they are doing, and are prepared to live with
occasionally (or frequently) testing using both types of compiler.

[Charles Richmond]

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

--
+-------------------------------
| Charles and Francis Richmond
| richmond at plano dot net
| Re-Defeat Bush!!!
+-------------------------------

[Greg Comeau]

In article <41***************@plano.net>,
Charles Richmond <ri******@nospam.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...

Not so.
G:\tmp>como --A --c90 notaslslcomment.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C90
G:\tmp>aout
Hi C!!!

G:\tmp>como --A --c99 notaslslcomment.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C99
G:\tmp>aout
Hi C!!!

G:\tmp>como --A --c++ notaslslcomment.cpp
Comeau C/C++ 4.3.4.1 (Sep 19 2004 11:33:48) for MS_WINDOWS_x86
Copyright 1988-2004 Comeau Computing. All rights reserved.
MODE:strict errors C++
G:\tmp>aout
Hi C!!!
--
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?

[Keith Thompson]

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

"Kenny McCormack" <ga*****@yin.interaccess.com> wrote

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.
The C++ folks could have made "@friend" or some similar illegal C construct
the keyword in their language, and allowed continued use of "friend" as an
identifier.

Yes, they could. I think Objective C took this approach.
Maybe this would have been a good idea.

I disagree. It would address the "problem" of C++ keywords that
aren't C keywords, but it wouldn't address any of the other
incompatibilities. C++ has good reasons for making character literals
have type char rather than int, and for disallowing implicit
conversions between void* and other pointer types, reasons that don't
apply to C. Marking the additional keywords doesn't address that.

I put "problem" in quotation marks because it really isn't a problem
in practice, as long as you decide which language you want to use and
use a compiler that handles that language.

Programming in C is easier than programming in the subset of C that's
consistent with C++, and few programmers have any good reason to do
the latter.

I almost think that the commonality of C and C++ does more harm than
good.

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

[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>