Differences between C and C++

L

Lew Pitcher

This may be a FAQ, but I did some searching and did not find an answer
that satisfied me.

I seem to remember people on this group claiming strongly that despite
their similarities, C and C++ are two different languages, and are
best treated as such.

Yes, both assertions are true.
C and C++ each have their own language definition, individually standardized
by both national and international standards bodies. It is not difficult to
locate copies of these standards documents, and a comparison of them will
show that C and C++ are two different languages, similar only in a small
subset.
Can anyone point me to a summary of the differences between these two
languages,

While I don't consider Wikipedia the best source of information, their web
page on the subject /does/ have a fair amount of accurate information:
http://en.wikipedia.org/wiki/Compatibility_of_C_and_C++
and also to information about the possible consequences of e.g. compiling
one language in a compiler intended for the other?
(Obviously, much of C++ will not compile at
all in a C compiler. That is not the interesting part.)

AFAIK, the consequences of using the wrong compiler are not defined by
either standard. Some compilers will happily compile C as C and C++ as C++,
while others will make some compiler-specific assumptions. In general, the
consequences of using the wrong compiler is that the resulting executable
program (if such is the result) may not generate the results expected of
it. Further specifics depend on the compiler, the level of the language
that it compiles, the code given to it to compile, and the expertise of the
programmer (or programmers) who wrote it (obviously, badly written code may
not compile, or may compile incorrectly, no matter which compiler is used).

HTH
 
K

Keith Thompson

Lew Pitcher said:
On February 9, 2011 14:59, in comp.lang.c, (e-mail address removed) wrote: [...]
and also to information about the possible consequences of e.g. compiling
one language in a compiler intended for the other?
(Obviously, much of C++ will not compile at
all in a C compiler. That is not the interesting part.)

AFAIK, the consequences of using the wrong compiler are not defined by
either standard. Some compilers will happily compile C as C and C++ as C++,
while others will make some compiler-specific assumptions. In general, the
consequences of using the wrong compiler is that the resulting executable
program (if such is the result) may not generate the results expected of
it. Further specifics depend on the compiler, the level of the language
that it compiles, the code given to it to compile, and the expertise of the
programmer (or programmers) who wrote it (obviously, badly written code may
not compile, or may compile incorrectly, no matter which compiler is used).

For most compilers (all the ones I've seen) that support both
C and C++, you have to tell the compiler which language you want
to compile. For example, gcc recognizes a file name ending in ".c"
as C source, and one ending in any of ".cc", ".cp", ".cxx", ".cpp",
".CPP", ".c++", or ".C" as C++. (I use ".cpp" myself.)
 
J

James Kuyper

Reposted to correct Google Groups foul-ups.

Yes, both assertions are true.
C and C++ each have their own language definition, individually standardized
by both national and international standards bodies. It is not difficult to
locate copies of these standards documents, and a comparison of them will
show that C and C++ are two different languages, similar only in a small
subset.

That subset could be called "small" by comparison with C++, since C++ is
such a large language. However, that subset has almost precisely the
same set of features as C itself. Most of the C features missing from
that subset are obsolescent features that most modern C programmers make
little or no use of, such as non-prototype functions, or recent C99
additions such as VLAs that have not yet gained wide popularity.

Most C programs can, with minor re-writes, be converted into code which
will compile with either language, with exactly the same meaning in both
languages. It's relatively easy to deliberately write code for which
this is not true; but such code is usually clearly contrived. It's
substantially harder to find code "in the wild", which was not
deliberately written for the purpose of showing up the
incompatibilities, which poses any serious problem for such a conversion.
While I don't consider Wikipedia the best source of information, their web
page on the subject /does/ have a fair amount of accurate information:
http://en.wikipedia.org/wiki/Compatibility_of_C_and_C++

Annex C of the C++ standard highlights most of the cases syntactically
valid C and C++ code has different meanings in both languages. The
number of ways in which this can happen is large, but most of them are
obscure cases that don't come up very often in modern well-written C code.
AFAIK, the consequences of using the wrong compiler are not defined by
either standard. ...

Many of the cases listed in Annex C of the C++ standard will eventually
cause constraint violations in one of the two languages - a diagnostic
is required. Most of the other cases will result in undefined behavior
in one of the two languages. There's only a few cases where it's
possible to write code with behavior that is defined in both languages,
and defined differently. The most prominent such difference is the type
of character constants. The others mostly involve the rules for name
spaces (not to be confused with C++ namespaces, which is a different
concept).
 
J

Jens

That subset could be called "small" by comparison with C++, since C++ is
such a large language. However, that subset has almost precisely the
same set of features as C itself. Most of the C features missing from
that subset are obsolescent features that most modern C programmers make
little or no use of, such as non-prototype functions, or recent C99
additions such as VLAs that have not yet gained wide popularity.

Calling C99 recent, I don't know, this are 12 years, now.

Besides VLA, C99 has other features that make it incompatible with C+
+, e.g macros with variable argument lists, inline with different
semantic, operators that return rvalues and not lvalues, ...

I don't think that it is good advice to consider C just as a "subset"
of C++, this is not very constructive. If you want to write good and
portable code write either C++ or C and do it well. E.g if you write C+
+ you implement constructors and an assignment operator, if you write
C you use initializers and "=", it makes not much sense to mix such
things.

Jens
 
J

James Kuyper

Calling C99 recent, I don't know, this are 12 years, now.

It's recent enough that full conforming implementations of it are still
uncommon; that's the sense that is relevant to my comment.

Also, while implementations are slowly adding the new C99 features,
recent revisions to C++ standard have also been adding them. The new C99
features that have been added to the C++ standard are mostly the same
ones that have been adopted most quickly by the less-than-fully
conforming implementations of C99 that are commonplace.
Besides VLA, C99 has other features that make it incompatible with C+
+, e.g macros with variable argument lists, inline with different
semantic, operators that return rvalues and not lvalues, ...

I don't think that it is good advice to consider C just as a "subset"
of C++, this is not very constructive. ...

Neither do I; but to imagine that the common subset of C and C++ is
"small" requires willfully ignoring the fact that almost every feature
of C is also a feature of C++; the exceptions are numerous, but still
quite small compared with the large number of shared features. The
common features are such ordinary commonplace things that they're easy
to ignore, but that doesn't mean they don't count. The common subset,
considered as a language in itself, is sufficiently powerful to perform
almost all of the same tasks as C itself. About the only thing it
doesn't do as well as C itself is identify whether the code was compiled
as C or C++, and that's just because, by definition, the constructs that
would allow you to determine which language was used are NOT allowed
when coding in the common subset.
 
J

John Bode

Yes, both assertions are true.
C and C++ each have their own language definition, individually standardized
by both national and international standards bodies. It is not difficult to
locate copies of these standards documents, and a comparison of them will
show that C and C++ are two different languages, similar only in a small
subset.

Each also have their own idioms and best practices; well-written C
code doesn't look or behave much like well-written C++ code.
 
J

Jorgen Grahn

Reposted to correct Google Groups foul-ups.
....

Thanks!

Meanwhile, Kenneth Brody said almost exactly what I wanted to say
(especially re: void* and malloc).

/Jorgen
 
D

Default User

James Kuyper said:
On 02/09/2011 02:53 AM, Jens wrote:

It's recent enough that full conforming implementations of it are still
uncommon; that's the sense that is relevant to my comment.

I would say that such is due more to lack of interest than recency. There
were pretty much fully-conforming C89/C90 compiler very soon after the
standard(s) were released.




Brian
 
A

Asbjørn Sæbø

This may be a FAQ, but I did some searching and did not find an answer
that satisfied me.

I seem to remember people on this group claiming strongly that despite
their similarities, C and C++ are two different languages, and are
best treated as such. Can anyone point me to a summary of the
differences between these two languages, and also to information about
the possible consequences of e.g. compiling one language in a compiler
intended for the other? (Obviously, much of C++ will not compile at
all in a C compiler. That is not the interesting part.)

With kind regards
Asbjørn Sæbø
 
A

Asbjørn Sæbø

Lew Pitcher said:
On February 9, 2011 14:59, in comp.lang.c, (e-mail address removed) wrote:
[...]
Can anyone point me to a summary of the differences between these two
languages,

While I don't consider Wikipedia the best source of information, their web
page on the subject /does/ have a fair amount of accurate information:
http://en.wikipedia.org/wiki/Compatibility_of_C_and_C++

Along with the references, this was actually quite along the lines of
what I wanted. Thanks! (Of course, I should have thought of checking
Wikipedia myself.

With kind regards
Asbjørn
 
E

Edward A. Falk

Calling C99 recent, I don't know, this are 12 years, now.

I consider it recent. In fact, anything that doesn't have about
99% adoption, I consider practically experimental.

I don't like to write code that won't compile everywhere. I was still
writing K&R C until about 10 years ago because Sun still had a compiler
that didn't know standard C.
 
I

Ian Collins

I consider it recent. In fact, anything that doesn't have about
99% adoption, I consider practically experimental.

I don't like to write code that won't compile everywhere. I was still
writing K&R C until about 10 years ago because Sun still had a compiler
that didn't know standard C.

Twenty years maybe, I bought my first Sun compiler in '92 and it was a
C89 compiler.
 
K

Keith Thompson

Ian Collins said:
Twenty years maybe, I bought my first Sun compiler in '92 and it was a
C89 compiler.

As I recall, for quite a while Sun had both a K&R C compiler and a C89
compiler (the latter was an optional add-on).
 
I

Ian Collins

As I recall, for quite a while Sun had both a K&R C compiler and a C89
compiler (the latter was an optional add-on).

The former was supplied with SunOS, back when users had to build their
own kernels!
 
J

James Kuyper

I would say that such is due more to lack of interest than recency. There
were pretty much fully-conforming C89/C90 compiler very soon after the
standard(s) were released.

Lack of interest is, if anything, more relevant than recency in the
context where I made that comment.
 
J

James Kuyper

Reposted to correct Google Groups foul-ups.

On 02/08/2011 03:07 PM, Lew Pitcher wrote: [...]
C and C++ each have their own language definition, individually
standardized
by both national and international standards bodies. It is not
difficult to
locate copies of these standards documents, and a comparison of them
will
show that C and C++ are two different languages, similar only in a small
subset.

That subset could be called "small" by comparison with C++, since C++ is
such a large language. However, that subset has almost precisely the same
set of features as C itself. Most of the C features missing from that
subset
are obsolescent features that most modern C programmers make little or no
use of, such as non-prototype functions, or recent C99 additions such as
VLAs that have not yet gained wide popularity.

My understanding is that C++ does not permit "void *" to be implicitly
converted to anything else, requiring an explicit cast instead.

Yes, that is one of the many features that are different, which does not
fall under either of those categories. While numerous, those features
constitute a tiny fraction compared to the number of features that C
shares with C++.
Virtually anything which uses malloc() for something other than "char *"
would need to be changed to work in C++. Hardly "clearly contrived".

That's an example of what I meant by "minor re-write", rather than
something I felt was "clearly contrived".
It is also not "contrived" to have a variable named "new", for example.

It is in most of the contexts I've seen it. In fact, the only C code
I've ever personally seen that used C++ keywords was written to use
those keywords because the author deliberately wanted to make it
difficult to port to C++. He felt he was doing future maintenance
programmers a service, by discouraging them from going over to the "dark
side".

While changing variable names is probably not difficult to do, the
addition of the required explicit cast on malloc() would probably be
pretty time consuming.

And, while changed variable names would have no effect on the code still
being able to be used as C, given that such a cast on malloc() is
considered "bad" in C, you will now have code that would no longer be
considered "good" C code.

I specified that the converted code would "compile with either language,
with exactly the same meaning in both languages". I didn't specify that
the code would be "good" or even "idiomatic" in either language. My
point was the very large number of shared features between the
languages; conversion of the type I describe would be next to impossible
if the shared subset of the two languages were in fact "small".
 
D

Default User

Keith Thompson said:
As I recall, for quite a while Sun had both a K&R C compiler and a C89
compiler (the latter was an optional add-on).

That was the case with HPUX in the 90s as well. There was a K&R included
that could be used for kernel builds (and would taunt you if you tried to
use certain ANSI features) and then you could buy a separate ANSI C
compiler.



Brian
 
C

Chris H

Asbjørn Sæbø said:
This may be a FAQ, but I did some searching and did not find an answer
that satisfied me.

I seem to remember people on this group claiming strongly that despite
their similarities, C and C++ are two different languages, and are
best treated as such. Can anyone point me to a summary of the
differences between these two languages, and also to information about
the possible consequences of e.g. compiling one language in a compiler
intended for the other? (Obviously, much of C++ will not compile at
all in a C compiler. That is not the interesting part.)

Looking at the chart on the wall C was incrementally developed from
BCPL that came from CPL.

in the 1970's we had K&R C, the first definition.
ANSI/ISO C was standardised in 1989/90 and then ISO C in 95 and 99

C++ was developed from "C with Classes" (1980) which was developed
from 1975 K&R C AND Simula 68

C++ came about in 1985 ish with influences from Algo 68 and additional
input from Simula 68

So there is a LOT of Simula in C++ as well as Algo

Moving on... in 1990 we had C++ ARM,( Annotated Reference Manual not
ARM MCU's ) developed from C++ but also with influences from Ada, ANSI
C, ML and CLu

C++ was further developed into the mid 90's when it became an ISO
standard.

So whilst sharing syntax that appears similar C and C++ diverged in
197* and whilst C carried on in one direction C++ was a hybrid of C and
Simula which was developed independently from C with influenced from 5
other languages.

The confusion generally arises because in the early days (from memory)
a front end call C-Front was used to translate C++ into C for
compilation until C++ compilers were built from scratch.

Thus the myth started that C++ was a super set of C.
 
B

BGB

Lack of interest is, if anything, more relevant than recency in the
context where I made that comment.

yep...

the edge cases are related to a few things one is left to ponder:
why/how should I implement this?...

(decided to leave out a bunch of stuff...).
 
T

Tim Rentsch

Chris H said:
Asbj@{o/}rn S@C3{A6}b@{o/} said:
This may be a FAQ, but I did some searching and did not find an answer
that satisfied me.

I seem to remember people on this group claiming strongly that despite
their similarities, C and C++ are two different languages, and are
best treated as such. Can anyone point me to a summary of the
differences between these two languages, and also to information about
the possible consequences of e.g. compiling one language in a compiler
intended for the other? (Obviously, much of C++ will not compile at
all in a C compiler. That is not the interesting part.)

Looking at the chart on the wall C was incrementally developed from
BCPL that came from CPL.

in the 1970's we had K&R C, the first definition.
ANSI/ISO C was standardised in 1989/90 and then ISO C in 95 and 99

C++ was developed from "C with Classes" (1980) which was developed
from 1975 K&R C AND Simula 68 [snip further]

I expect you mean Simula 67 -

http://en.wikipedia.org/wiki/Simula
 

Ask a Question

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

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

Ask a Question

Members online

No members online now.

Forum statistics

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

Latest Threads

Top