C++ compatible with C ?

[jjleto]

Can I assume that if a .c file compiles ok with gcc it will also compile
ok with a .cc extension with g++ ?

Any example where this does not work ?

regards,
jjleto

 

[Ron Natalie]

Can I assume that if a .c file compiles ok with gcc it will also compile
ok with a .cc extension with g++ ?

Absolutely not.

Any example where this does not work ?

Sure, one obvious example is that there are a few keywords in C++ that
aren't keywords in C.

Compile something like:
int class;

 

[Johannes Bretscher]

Can I assume that if a .c file compiles ok with gcc it will also compile
ok with a .cc extension with g++ ?

Any example where this does not work ?

I do not remember at the moment how strict gcc handles comments, but
there was this old example of
#v+
[...]
int i;
i = 8 //* Harhar */ 2
;
[...]
#v-

regards,
jjleto

Greeting,
Johannes

 

[Dave Vandervies]

Can I assume that if a .c file compiles ok with gcc it will also compile
ok with a .cc extension with g++ ?
No.

Any example where this does not work ?

Obvious example:
int old,new; /*Valid C, invalid C++*/

More subtle example:
--------
#include <stdio.h>
int main(void)
{
int i=42//**/
+7;
if(i==49)
if(sizeof 'a' == 1)
puts("C++ compiler or unusual byte size");
else /* // comments and 'a' is int*/
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
puts("C99 compiler");
#else
puts("broken C89 compiler");
#endif
else
puts("C89 compiler");

return 0;
}
--------
dave@goofy:~/clc (0) $ gcc test.c
dave@goofy:~/clc (0) $ ./a.out
broken C89 compiler
dave@goofy:~/clc (0) $ gcc -ansi test.c
dave@goofy:~/clc (0) $ ./a.out
C89 compiler
dave@goofy:~/clc (0) $ gcc -std=c99 test.c
dave@goofy:~/clc (0) $ ./a.out
C99 compiler
dave@goofy:~/clc (0) $ cp test.c test.cc
dave@goofy:~/clc (0) $ gcc test.cc
dave@goofy:~/clc (0) $ ./a.out
C++ compiler or unusual byte size
dave@goofy:~/clc (0) $

 

[Default User]

Can I assume that if a .c file compiles ok with gcc it will also compile
ok with a .cc extension with g++ ?

Any example where this does not work ?

Besides the others listed, there's the problem of void pointers. In C,
pointers to void can be assigned to any object pointer without a cast.
Not so in C++.



Brian

 

[Ioannis Vranos]

Can I assume that if a .c file compiles ok with gcc it will also compile
ok with a .cc extension with g++ ?

Any example where this does not work ?

C++, with few exceptions (=differences) retains C90 as a subset.
Regarding C99 vs C++98, there are *many* differences (e.g a built in
_Complex type).


Even with C90 itself there were differences. Two examples:

The implicit conversion of void * to any pointer type in C,

char c[2]="ab";

 

[Cy Edmunds]

Can I assume that if a .c file compiles ok with gcc it will also compile
ok with a .cc extension with g++ ?

Any example where this does not work ?

regards,
jjleto

http://www.research.att.com/~bs/3rd_compat.pdf

 

[Karthik Kumar]

Obvious example:
int old,new; /*Valid C, invalid C++*/

More subtle example:
--------
#include <stdio.h>
int main(void)
{
int i=42//**/
+7;
if(i==49)
if(sizeof 'a' == 1)
puts("C++ compiler or unusual byte size");
else /* // comments and 'a' is int*/
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L

Just curious, is this macro specified by the C standard,
or only restricted to GNU implementation.

 

[David Lindauer]

Just curious, is this macro specified by the C standard,
or only restricted to GNU implementation.

it is specified by the standard.

David

 

[john blackburn]

Can I assume that if a .c file compiles ok with gcc it will also compile
ok with a .cc extension with g++ ?

Any example where this does not work ?

regards,
jjleto

I think, in practical terms, yes; as other posts point out, you may have the
occasional small issue to fix.

Interestingly I tried to compile something I wrote in Borland C++ with g++
and had a couple of issues with that even; despite my attempts to avoid
using anything other than absolute standard C++ issue 3. Different
compilers can be fussier about certain syntactical issues than others.

 

[Arijit]

Can I assume that if a .c file compiles ok with gcc it will also compile
ok with a .cc extension with g++ ?

Any example where this does not work ?

regards,
jjleto

C99 has a few things that C++ doesn't. For example, Variable Length Arrays.

void foo(int m)
{
int x[m];
}

compiles in C, not C++.

 

[Rolf Magnus]

dave@goofy:~/clc (0) $ cp test.c test.cc
dave@goofy:~/clc (0) $ gcc test.cc
dave@goofy:~/clc (0) $ ./a.out
C++ compiler or unusual byte size
dave@goofy:~/clc (0) $
--------

What exactly do you mean by "unusual byte size"? "Byte" is by definition the
size of a char in C as well as in C++, i.e. sizeof(char) is always 1.

 

[Dave Vandervies]

What exactly do you mean by "unusual byte size"? "Byte" is by definition the
size of a char in C as well as in C++, i.e. sizeof(char) is always 1.

It's referring to bit count; in C, character constants have type int,
so the program attempts to identify C++ by checking sizeof 'a' (which is
sizeof(char) in C++ and sizeof(int) in C). But if CHAR_BIT is not less
than 16, sizeof(int) is allowed to be 1, and the program can't correctly
identify that case.

Calling this "unusual" is a modern-general-purpose-processor-centric
assumption, but it's the best I could do with the time I was willing to
put into it.


dave

 

[Stewart Gordon]

David Lindauer wrote:

it is specified by the standard.

Then why does it begin with __? I thought that was for
implementation-specific features.

Stewart.

 

[Rob Williscroft]

Stewart Gordon wrote in in
comp.lang.c++:

David Lindauer wrote:


Then why does it begin with __? I thought that was for
implementation-specific features.

It is, *except* where the Standard has previously reserved the
identifier.

Also __STDC_VERSION__ is only defined in C99 not C++, C++ does
define __STDC__ though (which it got from C89 AIUI).

Rob.

 

[Ron Natalie]

Then why does it begin with __? I thought that was for
implementation-specific features.

You thought wrong. The __ is RESERVED for the implementation,
that means YOU CAN'T USE THEM. It doesn't mean the standard
doesn't define some symbols in the reserved space.

 

[Dave Vandervies]

Also __STDC_VERSION__ is only defined in C99 not C++, C++ does
define __STDC__ though (which it got from C89 AIUI).

It was actually introduced in C95, a rather less severe update to C90
than C99 was.
I believe that it was introduced to avoid changing the value of 1 for
__STDC__, so that programs that checked it for `equal to 1' and not for
`defined and nonzero' wouldn't break.

(Does C++ also define __STDC__ as 1? That seems an odd choice to me.)


dave

 

[Dave Vandervies]

I think, in practical terms, yes; as other posts point out, you may have the
occasional small issue to fix.

In practical terms, a nontrivial chunk of well-written C code will be
unlikely to compile as C++ without modification. The conversion to
something that a C++ compiler will do the right thing with should be
fairly straightforward, since most of the constructs that are valid in
both languages but have different meaning aren't considered `good code'
in either (though even there I'm sure there are exceptions), but the
resulting code won't be identical.

Of course, trying to write in the common subset of the two languages is
even worse, unless you have a Really Good Reason.


dave

 

[Rob Williscroft]

Dave Vandervies wrote in in
comp.lang.c++:

It was actually introduced in C95, a rather less severe update to C90
than C99 was.

Thanks, I'll try to remeber that but I can't make any guarantees .

I believe that it was introduced to avoid changing the value of 1 for
__STDC__, so that programs that checked it for `equal to 1' and not for
`defined and nonzero' wouldn't break.

(Does C++ also define __STDC__ as 1? That seems an odd choice to me.)

16.9/1
....

__STDC__ Whether __STDC__ is predefined and if so, what its value
is, are implementation-defined.

So it only really allows it to be defined , its still a reserved
identifier though, so:

#if defined( __STDC__ )

is portable.

Rob.

 

[Stewart Gordon]

You thought wrong. The __ is RESERVED for the implementation,
that means YOU CAN'T USE THEM. It doesn't mean the standard
doesn't define some symbols in the reserved space.

Oh, so the range of identifiers is double-booked. So an implementation
can define something beginning with __, only for a later version of the
standard to redefine it to mean something completely different and
potentially break lots of legacy code.

What's the point of reserving identifiers if it's done in a way that
such conflicts are bound to arise?

Stewart.