Any C code are valid C++ code?
jrefa...@hotmail.com
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
> Since C is a subset of C++ [...]
Wrong premise. Wrong conclusion. The answer to your subj is "no".
gianguz
(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
> 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" <joh...@eskimo.com> wrote in message news:41b9ebca$1...@news.tulsaconnect.com...
> jrefa...@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 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
> 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
<jrefa...@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) +1 801 277 2603
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
<ale...@big-foot.com> wrote:
>"Jonathan Bartlett" <joh...@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.
jco...@taeus.com
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
>>> * 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
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
E. Robert Tisdale <E.Robert...@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
> On Fri, 10 Dec 2004 20:42:03 +0200, in comp.lang.c , "Alex Vinokur"
> <ale...@big-foot.com> wrote:
>
> >"Jonathan Bartlett" <joh...@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
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
> 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
>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
> 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
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, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Victor Bazarov
> [...] 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
> 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
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" <chbarts...@gmail.com> wrote
> > Since C is a subset of C++,
>
> Wrong. A common notion that is completely wrong.
>
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
E. Robert Tisdale <E.Robert...@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
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.
Malcolm
>
> 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.
>
because C++ was more in keeping with the image of the company.
Joona I Palaste
on comp.lang.c:
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 (pal...@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen
Kenny McCormack
Chris Barts <chbarts...@gmail.com> wrote:
>jrefa...@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
"Victor Bazarov" <v.Aba...@comAcast.net> wrote:
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
<pal...@cc.helsinki.fi> wrote:
>Mark McIntyre <markmc...@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.
Greg Comeau
Mark McIntyre <markmc...@spamcop.net> wrote:
>On 11 Dec 2004 18:20:05 GMT, in comp.lang.c , Joona I Palaste
><pal...@cc.helsinki.fi> wrote:
>
>>Mark McIntyre <markmc...@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
...
> 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
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
> 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;
E. Robert Tisdale
> 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 <7d6mr0h2qs3t2qtfh...@4ax.com> Mark McIntyre <markmc...@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
>In article <l73nr09j0gsgksjpp...@4ax.com> Mark McIntyre <markmc...@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".
Chris Barts
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
> In article <9KCdnbRypJ-...@onewest.net>,
> Chris Barts <chbarts...@gmail.com> wrote:
>
>>jrefa...@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" <gaz...@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 keyword in their language, and allowed continued use of "friend" as an
identifier. Maybe this would have been a good idea.
Mark McIntyre
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
<Dik.W...@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.
>In both cases using 'a' will in general lead to strange behaviour of the
>program.
Strange behaviour in this case including working as expected....
Mark McIntyre
<Dik.W...@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?
Flash Gordon
"E. Robert Tisdale" <E.Robert...@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
Mark McIntyre <markmc...@spamcop.net> wrote:
>On 11 Dec 2004 19:35:13 -0500, in comp.lang.c , com...@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.
robert...@antenova.com
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...@antenova.com
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
>
> On 11 Dec 2004 19:35:13 -0500, in comp.lang.c , com...@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.
>
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
Charles Richmond <rich...@nospam.plano.net> wrote:
>Mark McIntyre wrote:
>>
>> On 11 Dec 2004 19:35:13 -0500, in comp.lang.c , com...@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!!!
Keith Thompson
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
Comeau) wrote:
>In article <41BCB499...@plano.net>,
>Charles Richmond <rich...@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++.
Keith Thompson
> On 12 Dec 2004 15:22:18 -0500, in comp.lang.c , com...@panix.com (Greg
> Comeau) wrote:
>
>>In article <41BCB499...@plano.net>,
>>Charles Richmond <rich...@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++.
Dik T. Winter
> Dik T. Winter wrote:
...
> 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
...
> 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
> 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
> On Sun, 12 Dec 2004 01:25:35 GMT, in comp.lang.c , "Dik T. Winter"
> <Dik.W...@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
> On Sun, 12 Dec 2004 01:56:03 GMT, in comp.lang.c , "Dik T. Winter"
> <Dik.W...@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"?
Greg Comeau
Mark McIntyre <markmc...@spamcop.net> wrote:
>On 12 Dec 2004 15:22:18 -0500, in comp.lang.c , com...@panix.com (Greg
>Comeau) wrote:
>
>>In article <41BCB499...@plano.net>,
>>Charles Richmond <rich...@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
Keith Thompson <ks...@mib.org> wrote:
>Mark McIntyre <markmc...@spamcop.net> writes:
>> On 12 Dec 2004 15:22:18 -0500, in comp.lang.c , com...@panix.com (Greg
>> Comeau) wrote:
>>>In article <41BCB499...@plano.net>,
>>>Charles Richmond <rich...@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.
Ron House
> "Chris Barts" <chbarts...@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
wrote:
>Mark McIntyre wrote:
>>
>> On 11 Dec 2004 19:35:13 -0500, in comp.lang.c , com...@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
>
> The difference between C++ and C is that in C++ conversions between
> incompatible pointer types are not allowed. In C they are allowed,
> produce what you think it should produce:
>
>
> 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" <mal...@55bank.freeserve.co.uk> wrote in message
news:cpf9tn$qdt$1...@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...@my-deja.com
jrefa...@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
> "Malcolm" <mal...@55bank.freeserve.co.uk> wrote in message
> news:cpf9tn$qdt$1...@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" <r...@hoekstra-uitgeverij.nl> wrote in message
news:41befa3d....@news.individual.net...
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
<ks...@mib.org> wrote:
>Mark McIntyre <markmc...@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
<Dik.W...@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.
Dave Thompson
On Sat, 11 Dec 2004 16:11:59 +0000, Mark McIntyre
<markmc...@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