Compatibility of C and C++: Difference between revisions
Undid revision 814781926 by Special:Contributions/2604:2000:B053:1600:129A:DDFF:FEA5:CAE7- not clear what "truly" related means |
|||
(110 intermediate revisions by 54 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Comparison of programming languages}} |
|||
{{ProgLangCompare}} |
{{ProgLangCompare}} |
||
The [[C programming language|C]] and [[C++]] [[programming languages]] are closely related but |
The [[C (programming language)|C]] and [[C++]] [[programming languages]] are closely related but have many significant differences. C++ began as a [[Fork (software development)|fork]] of an early, pre-[[ANSI C|standardized]] C, and was designed to be mostly source-and-link compatible with C compilers of the time.<ref name="overview">{{cite web | url=http://www.stroustrup.com/crc.pdf | title=An Overview of the C++ Programming Language in The Handbook of Object Technology (Editor: Saba Zamir). CRC Press LLC, Boca Raton. 1999. ISBN 0-8493-3135-8. | first=Bjarne | last=Stroustrup | author-link=Bjarne Stroustrup | page=4 | access-date=12 August 2009 | url-status=live | archive-url=https://web.archive.org/web/20120816122304/http://www.stroustrup.com/crc.pdf | archive-date=16 August 2012 | df=dmy-all }}</ref><ref>{{cite web |url=http://www.stroustrup.com/siblings_short.pdf |title=C and C++: Siblings. The C/C++ Users Journal. July 2002.|author=B.Stroustrup |access-date=17 March 2019}}</ref> Due to this, development tools for the two languages (such as [[Integrated development environment|IDEs]] and [[compiler]]s) are often integrated into a single product, with the programmer able to specify C or C++ as their source language. |
||
However, C is not a [[subset]] of C++,<ref name="subset">{{cite web|url=http://www. |
However, C is ''not'' a [[subset]] of C++,<ref name="subset">{{cite web |url=http://www.stroustrup.com/bs_faq.html#C-is-subset |title=Bjarne Stroustrup's FAQ – Is C a subset of C++? |access-date=22 Sep 2019}}</ref> and nontrivial C programs will not compile as C++ code without modification. Likewise, C++ introduces many features that are not available in C and in practice almost all code written in C++ is not conforming C code. This article, however, focuses on differences that cause conforming C code to be ill-formed C++ code, or to be conforming/well-formed in both languages but to behave differently in C and C++. |
||
[[Bjarne Stroustrup]], the creator of C++, has suggested<ref>{{cite web|url=http://www. |
[[Bjarne Stroustrup]], the creator of C++, has suggested<ref>{{cite web |url=http://www.stroustrup.com/compat_short.pdf |title=C and C++: A Case for Compatibility. The C/C++ Users Journal. August 2002.|author=B. Stroustrup |access-date=18 August 2013 |url-status=live |archive-url=https://web.archive.org/web/20120722012742/http://www2.research.att.com/~bs/compat_short.pdf |archive-date=22 July 2012 |df=dmy-all }}</ref> that the incompatibilities between C and C++ should be reduced as much as possible in order to maximize interoperability between the two languages. Others have argued that since C and C++ are two different languages, compatibility between them is useful but not vital; according to this camp, efforts to reduce incompatibility should not hinder attempts to improve each language in isolation. The official rationale for the 1999 C standard ([[C99]]) "endorse<nowiki>[d]</nowiki> the principle of maintaining the largest common subset" between C and C++ "while maintaining a distinction between them and allowing them to evolve separately", and stated that the authors were "content to let C++ be the big and ambitious language."<ref>[http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf Rationale for International Standard—Programming Languages—C] {{webarchive|url=https://web.archive.org/web/20160606072228/http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf |date=6 June 2016 }}, revision 5.10 (April 2003).</ref> |
||
Several additions of C99 are not supported in the current C++ standard or conflicted with C++ features, such as [[Variable Length Array|variable-length arrays]], native [[complex data type|complex number]] types |
Several additions of C99 are not supported in the current C++ standard or conflicted with C++ features, such as [[Variable Length Array|variable-length arrays]], native [[complex data type|complex number]] types and the <code>[[restrict]]</code> [[type qualifier]]. On the other hand, C99 reduced some other incompatibilities compared with C89 by incorporating C++ features such as <code>//</code> comments and mixed declarations and code.<ref>{{cite web|url=https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html|title=C Dialect Options - Using the GNU Compiler Collection (GCC)|work=gnu.org|url-status=live|archive-url=https://web.archive.org/web/20140326130603/http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html|archive-date=26 March 2014|df=dmy-all}}</ref> |
||
==Constructs valid in C but not in C++== |
==Constructs valid in C but not in C++== |
||
C++ enforces stricter typing rules |
C++ enforces stricter typing rules (no implicit violations of the static type system<ref name="overview" />), and initialization requirements (compile-time enforcement that in-scope variables do not have initialization subverted)<ref>{{cite web|url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf|title=N4659: Working Draft, Standard for Programming Language C++|at=§Annex C.1|url-status=live|archive-url=https://web.archive.org/web/20171207092618/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf|archive-date=7 December 2017|df=dmy-all}} ("It is invalid to jump past a declaration with explicit or implicit initializer (except across entire block not entered). … With this simple compile-time rule, C++ assures that if an initialized variable is in scope, then it has assuredly been initialized.")</ref> than C, and so some valid C code is invalid in C++. A rationale for these is provided in Annex C.1 of the ISO C++ standard.<ref>{{cite web|url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf|title=N4659: Working Draft, Standard for Programming Language C++|at=§Annex C.1|url-status=live|archive-url=https://web.archive.org/web/20171207092618/http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf|archive-date=7 December 2017|df=dmy-all}}</ref> |
||
⚫ | |||
{{bulleted list |
|||
⚫ | |||
⚫ | |1= One commonly encountered difference is C being more [[Strong and weak typing|weakly-typed]] regarding pointers. Specifically, C allows a <code>void*</code> pointer to be assigned to any pointer type without a cast, while C++ does not; this [[Programming idiom|idiom]] appears often in C code using <code>malloc</code> memory allocation,<ref name="publib.boulder.ibm.com">{{cite web|url=http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=%2Fcom.ibm.vacpp6m.doc%2Flanguage%2Fref%2Fclrc07cplr243.htm|title=IBM Knowledge Center|work=ibm.com}}</ref> or in the passing of context pointers to the POSIX [[pthreads]] API, and other frameworks involving [[callbacks]]. For example, the following is valid in C but not C++: |
||
⚫ | |||
/* Implicit conversion from void* to int* */ |
/* Implicit conversion from void* to int* */ |
||
int *i = ptr; |
int *i = ptr; |
||
</syntaxhighlight> |
|||
</source> |
|||
or similarly: |
|||
< |
<syntaxhighlight lang="c">int *j = malloc(5 * sizeof *j); /* Implicit conversion from void* to int* */</syntaxhighlight> |
||
In order to make the code compile as both C and C++, one must use an explicit cast, as follows (with some caveats in both languages<ref>{{cite web|url=http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?id=1043284351&answer=1047673478|title=FAQ > Casting malloc - Cprogramming.com|website=faq.cprogramming.com|url-status=live|archive-url=https://web.archive.org/web/20070405121807/http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1047673478&id=1043284351|archive-date=5 April 2007|df=dmy-all}}</ref><ref>{{cite web|url=http://www.learncpp.com/cpp-tutorial/4-4a-explicit-type-conversion-casting/|title=4.4a — Explicit type conversion (casting)|date=16 April 2015|url-status=live|archive-url=https://web.archive.org/web/20160925003229/http://www.learncpp.com/cpp-tutorial/4-4a-explicit-type-conversion-casting/|archive-date=25 September 2016|df=dmy-all}}</ref>): |
|||
< |
<syntaxhighlight lang="c++"> |
||
void |
void *ptr; |
||
int *i = (int *)ptr; |
int *i = (int *)ptr; |
||
int *j = (int *)malloc( |
int *j = (int *)malloc(5 * sizeof *j); |
||
</syntaxhighlight> |
|||
</source> |
|||
|2= C++ has more complicated rules about pointer assignments that add qualifiers as it allows the assignment of <code>int **</code> |
|||
* C++ is also more strict than C about pointer assignments that discard a <code>const</code> qualifier (e.g. assigning a <code>const int*</code> value to an <code>int*</code> variable): in C++ this is invalid and generates a compiler error (unless an explicit typecast is used),<ref>{{cite web|author= |url=http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.17 |title=Const correctness, C++ FAQ |publisher=Parashift.com |date=4 July 2012 |accessdate=18 August 2013}}</ref> whereas in C this is allowed (although many compilers emit a warning). |
|||
to <code>const int *const *</code> but not the unsafe assignment to <code>const int **</code> while C allows neither of those (although compilers will usually only emit a warning). |
|||
|3= C++ changes some [[C standard library]] functions to add additional overloaded functions with <code>[[Const (computer programming)|const]]</code> [[type qualifier]]s, e.g. <code>strchr</code> returns <code>char*</code> in C, while C++ acts as if there were two overloaded functions <code>const char *strchr(const char *)</code> and a <code>char *strchr(char *)</code>. In [[C23 (C standard revision)|C23]] generic selection will be used to make C's behaviour more similar to C++'s.<ref>{{cite web|url=https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3020.pdf|title=Qualifier-preserving standard library functions, v4}}</ref> |
|||
|4= C++ is also more strict in conversions to enums: ints cannot be implicitly converted to enums as in C. Also, [[enumerated type#C and syntactically similar languages|enumeration constants]] (<code>enum</code> enumerators) are always of type <code>int</code> in C, whereas they are distinct types in C++ and may have a size different from that of <code>int</code>.{{update inline|reason=In C23 the underlying type of an enum can be different from int. See [https://open-std.org/JTC1/SC22/WG14/www/docs/n3029.htm N3029] and [https://open-std.org/JTC1/SC22/WG14/www/docs/n3030.htm N3030].|date=February 2024}} |
|||
|5= In C++ a <code>const</code> variable must be initialized; in C this is not necessary. |
|||
|6= C++ compilers prohibit goto or switch from crossing an initialization, as in the following C99 code: |
|||
< |
<syntaxhighlight lang="c"> |
||
void fn(void) |
void fn(void) |
||
{ |
{ |
||
goto flack; |
goto flack; |
||
int i = 1; |
int i = 1; |
||
flack: |
|||
; |
|||
} |
} |
||
</syntaxhighlight> |
|||
</source> |
|||
|7= While syntactically valid, a [[longjmp|<code>longjmp()</code>]] results in undefined behaviour in C++ if the jumped-over [[stack frame]]s include objects with nontrivial destructors.<ref>{{cite web|url=http://www.cplusplus.com/reference/csetjmp/longjmp/|title=longjmp - C++ Reference|website=www.cplusplus.com|url-status=live|archive-url=https://web.archive.org/web/20180519163512/http://www.cplusplus.com/reference/csetjmp/longjmp/|archive-date=19 May 2018|df=dmy-all}}</ref> The C++ implementation is free to define the behaviour such that destructors would be called. However, this would preclude some uses of <code>longjmp()</code> which would otherwise be valid, such as implementation of [[Thread (computing)|threads]] or [[coroutines]] switching between separate call stacks with <code>longjmp()</code> — when jumping from the lower to the upper call stack in global address space, destructors would be called for every object in the lower call stack. No such issue exists in C. |
|||
|8= C allows for multiple tentative definitions of a single global variable in a single [[Translation unit (programming)|translation unit]], which is invalid as an [[One Definition Rule|ODR]] violation in C++. |
|||
< |
<syntaxhighlight lang="c"> |
||
int N; |
int N; |
||
int N = 10; |
int N = 10; |
||
</syntaxhighlight> |
|||
</source> |
|||
|9= In C, declaring a new type with the same name as an existing <code>struct</code>, <code>union</code> or <code>enum</code> is valid, but it is invalid in C++, because in C, <code>struct</code>, <code>union</code>, and <code>enum</code> types must be indicated as such whenever the type is referenced whereas in C++, all declarations of such types carry the [[typedef]] implicitly. |
|||
< |
<syntaxhighlight lang="c"> |
||
enum BOOL {FALSE, TRUE}; |
enum BOOL {FALSE, TRUE}; |
||
typedef int BOOL; |
typedef int BOOL; |
||
</syntaxhighlight> |
|||
</source> |
|||
|10= Non-prototype ("K&R"-style) function declarations are invalid in C++; they are still valid in C until C23,<ref name=N2432>{{cite web|url=https://open-std.org/JTC1/SC22/WG14/www/docs/n2432.pdf|title=WG14 N2432 : Remove support for function definitions with identifier lists}}</ref><ref>{{cite web|url=http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1570.pdf|title=2011 ISO C draft standard}}</ref> although they have been deemed obsolescent since C's original standardization in 1990. (The term "obsolescent" is a defined term in the ISO C standard, meaning a feature that "may be considered for withdrawal in future revisions" of the standard.) Similarly, implicit function declarations (using functions that have not been declared) are not allowed in C++, and have been invalid in C since 1999. |
|||
|11= In C until C23,<ref name=N2841>{{cite web|url=https://open-std.org/JTC1/SC22/WG14/www/docs/n2841.htm|title= WG14 N 2841: No function declarators without prototypes}}</ref> a function declaration without parameters, e.g. <code>int foo();</code>, implies that the parameters are unspecified. Therefore, it is legal to call such a function with one or more [[argument (computer programming)|argument]]s, e.g. <code>foo(42, "hello world")</code>. In contrast, in C++ a function prototype without arguments means that the function takes no arguments, and calling such a function with arguments is ill-formed. In C, the correct way to declare a function that takes no arguments is by using 'void', as in <code>int foo(void);</code>, which is also valid in C++. Empty function prototypes are a deprecated feature in C99 (as they were in C89). |
|||
|12= In both C and C++, one can define nested <code>[[struct (C programming language)|struct]]</code> types, but the scope is interpreted differently: in C++, a nested <code>struct</code> is defined only within the scope/namespace of the outer <code>struct</code>, whereas in C the inner struct is also defined outside the outer struct. |
|||
⚫ | |||
}} |
|||
[[C99]] and [[C11 (C standard revision)|C11]] added several additional features to C that have not been incorporated into standard C++, such as complex numbers, variable length arrays ( |
[[C99]] and [[C11 (C standard revision)|C11]] added several additional features to C that have not been incorporated into standard C++ as of [[C++20]], such as complex numbers, variable length arrays (complex numbers and variable length arrays are designated as optional extensions in C11), [[flexible array member]]s, the [[restrict]] keyword, array parameter qualifiers, and [[C syntax#Compound literals|compound literals]]. |
||
{{bulleted list |
|||
|1= [[Complex arithmetic]] using the <code>float complex</code> and <code>double complex</code> primitive data types was added in the [[C99]] standard, via the <code>_Complex</code> keyword and <code>complex</code> convenience macro. In C++, complex arithmetic can be performed using the complex number class, but the two methods are not code-compatible. (The standards since [[C++11]] require binary compatibility, however.)<ref>{{cite web|url=http://en.cppreference.com/w/cpp/numeric/complex|title=std::complex - cppreference.com|website=en.cppreference.com|url-status=live|archive-url=https://web.archive.org/web/20170715125445/http://en.cppreference.com/w/cpp/numeric/complex|archive-date=15 July 2017|df=dmy-all}}</ref> |
|||
|2= Variable length arrays. This feature leads to possibly non-compile time {{mono|[[sizeof]]}} operator.<ref>{{cite web|title=Incompatibilities Between ISO C and ISO C++|url=http://david.tribble.com/text/cdiffs.htm#C90-vs-CPP98|url-status=live|archive-url=https://web.archive.org/web/20060409075755/http://david.tribble.com/text/cdiffs.htm#C90-vs-CPP98|archive-date=9 April 2006|df=dmy-all}}</ref> |
|||
< |
<syntaxhighlight lang="C"> |
||
void foo(size_t x, int a[*]); // VLA declaration |
void foo(size_t x, int a[*]); // VLA declaration |
||
void foo(size_t x, int a[x]) |
void foo(size_t x, int a[x]) |
||
{ |
{ |
||
printf("%zu\n", sizeof a); // same as sizeof(int*) |
printf("%zu\n", sizeof a); // same as sizeof(int*) |
||
char s[x*2]; |
char s[x * 2]; |
||
printf("%zu\n", sizeof s); // will print x*2 |
printf("%zu\n", sizeof s); // will print x*2 |
||
} |
} |
||
</syntaxhighlight> |
|||
</source> |
|||
<!-- * C99 allows declaration of function macros with empty arguments. For example macro <code>#define ADD(A,B) (A+B)</code> applied to <code>ADD(4,)</code> will be evaluated to <code>(4+)</code> --> |
<!-- * C99 allows declaration of function macros with empty arguments. For example macro <code>#define ADD(A,B) (A+B)</code> applied to <code>ADD(4,)</code> will be evaluated to <code>(4+)</code> --> |
||
|3= The last member of a C99 structure type with more than one member may be a [[flexible array member]], which takes the syntactic form of an array with unspecified length. This serves a purpose similar to variable-length arrays, but VLAs cannot appear in type definitions, and unlike VLAs, flexible array members have no defined size. ISO C++ has no such feature. Example: |
|||
< |
<syntaxhighlight lang="C"> |
||
struct X |
struct X |
||
{ |
{ |
||
Line 92: | Line 99: | ||
char bytes[]; |
char bytes[]; |
||
} |
} |
||
</syntaxhighlight> |
|||
</source> |
|||
|4= The <code>[[restrict]]</code> [[type qualifier]] defined in C99 was not included in the C++03 standard, but most mainstream compilers such as the [[GNU Compiler Collection]],<ref>[https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html#Restricted-Pointers Restricted Pointers] {{webarchive|url=https://web.archive.org/web/20160806092010/http://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html |date=6 August 2016 }} from ''Using the GNU Compiler Collection (GCC)''</ref> [[Microsoft Visual C++]], and [[Intel C++ Compiler]] provide similar functionality as an extension. |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
int bar(char s[static 5]); // annotates that s is at least 5 chars long |
int bar(char s[static 5]); // annotates that s is at least 5 chars long |
||
</syntaxhighlight> |
|||
</source> |
|||
|6= The functionality of [[C syntax#Compound literals|compound literals]] in C is generalized to both built-in and user-defined types by the list initialization syntax of C++11, although with some syntactic and semantic differences. |
|||
⚫ | |||
struct X a = (struct X){4, 6}; // The equivalent in C++ would be X{4, 6}. The C syntactic form used in C99 is supported as an extension in the GCC and Clang C++ compilers. |
|||
foo(&(struct X){4, 6}); // The object is allocated in the stack and its address can be passed to a function. This is not supported in C++. |
|||
if (memcmp(d, (int []){8, 6, 7, 5, 3, 0, 9}, n) == 0) {} // The equivalent in C++ would be using digits = int []; if (memcmp(d, digits{8, 6, 7, 5, 3, 0, 9}, n) == 0) {} |
|||
⚫ | |||
</syntaxhighlight> |
|||
⚫ | |||
struct X a = {.n = 4, .m = 6}; |
|||
⚫ | |||
</source> |
|||
⚫ | |||
⚫ | |||
<syntaxhighlight lang="C"> |
|||
⚫ | |||
</syntaxhighlight> |
|||
|8= Functions that do not return can be annotated using a <code>noreturn</code> [[C++11#Attributes|attribute]] in C++ whereas C uses a distinct keyword. In C23, the attribute syntax is also supported.<ref name="N2764">{{cite web |title=WG14-N2764 : The noreturn attribute |url=https://open-std.org/JTC1/SC22/WG14/www/docs/n2764.pdf |website=open-std.org |archive-url=https://web.archive.org/web/20221225063437/https://open-std.org/JTC1/SC22/WG14/www/docs/n2764.pdf |archive-date=December 25, 2022 |date=2021-06-21 |url-status=live}}</ref> |
|||
}} |
|||
C++ adds numerous additional keywords to support its new features. This renders C code using those keywords for identifiers invalid in C++. For example: |
C++ adds numerous additional keywords to support its new features. This renders C code using those keywords for identifiers invalid in C++. For example: |
||
< |
<syntaxhighlight lang="c"> |
||
struct template |
struct template |
||
{ |
{ |
||
Line 117: | Line 133: | ||
struct template* class; |
struct template* class; |
||
}; |
}; |
||
</syntaxhighlight> |
|||
</source> |
|||
:is valid C code, but is rejected by a C++ compiler, since the keywords |
:is valid C code, but is rejected by a C++ compiler, since the keywords <code>template</code>, <code>new</code> and <code>class</code> are reserved. |
||
==Constructs that behave differently in C and C++== |
==Constructs that behave differently in C and C++== |
||
There are a few |
There are a few syntactic constructs that are valid in both C and C++ but produce different results in the two languages. |
||
* [[Character literal]]s such as <code>'a'</code> are of type <code>int</code> in C and of type <code>char</code> in C++, which means that <code>sizeof 'a'</code><!--Thought this was an error for sizeof('a') but both seems to work--> will generally give different results in the two languages: in C++, it will be <code>1</code>, while in C it will be <code>sizeof(int)</code>. As another consequence of this type difference, in C, <code>'a'</code> will always be a signed expression, regardless of whether or not <code>char</code> is a signed or unsigned type, whereas for C++ this is compiler implementation specific. |
* [[Character literal]]s such as <code>'a'</code> are of type <code>int</code> in C and of type <code>char</code> in C++, which means that <code>sizeof 'a'</code><!--Thought this was an error for sizeof('a') but both seems to work--> will generally give different results in the two languages: in C++, it will be <code>1</code>, while in C it will be <code>sizeof(int)</code>. As another consequence of this type difference, in C, <code>'a'</code> will always be a signed expression, regardless of whether or not <code>char</code> is a signed or unsigned type, whereas for C++ this is compiler implementation specific. |
||
* C++ assigns internal linkage to namespace-scoped <code>const</code> variables unless they are explicitly declared <code>[[External variable|extern]]</code>, unlike C in which <code>extern</code> is the default for all file-scoped entities. |
* C++ assigns internal linkage to namespace-scoped <code>const</code> variables unless they are explicitly declared <code>[[External variable|extern]]</code>, unlike C in which <code>extern</code> is the default for all file-scoped entities. In practice this does not lead to silent semantic changes between identical C and C++ code but instead will lead to a compile-time or linkage error. |
||
* C distinguishes two kinds of definitions of [[Inline function|<code>inline</code> functions]]: ordinary external definitions (where |
* In C, use of inline functions requires manually adding a prototype declaration of the function using the extern keyword in exactly one translation unit to ensure a non-inlined version is linked in, whereas C++ handles this automatically. In more detail, C distinguishes two kinds of definitions of [[Inline function|<code>inline</code> functions]]: ordinary external definitions (where <code>extern</code> is explicitly used) and inline definitions. C++, on the other hand, provides only inline definitions for inline functions. In C, an inline definition is similar to an internal (i.e. static) one, in that it can coexist in the same program with one external definition and any number of internal and inline definitions of the same function in other translation units, all of which can differ. This is a separate consideration from the ''linkage'' of the function, but not an independent one. C compilers are afforded the discretion to choose between using inline and external definitions of the same function when both are visible. C++, however, requires that if a function with external linkage is declared <code>inline</code> in any translation unit then it must be so declared (and therefore also defined) in every translation unit where it is used, and that all the definitions of that function be identical, following the ODR. Static inline functions behave identically in C and C++. |
||
* Both C99 and C++ have a [[Boolean data type| |
* Both C99 and C++ have a [[Boolean data type|Boolean type]] <code>bool</code> with constants <code>true</code> and <code>false</code>, but they are defined differently. In C++, <code>bool</code> is a [[Primitive data type|built-in type]] and a [[Reserved word|reserved keyword]]. In C99, a new keyword, <code>_Bool</code>, is introduced as the new Boolean type. The header <code>stdbool.h</code> provides macros <code>bool</code>, <code>true</code> and <code>false</code> that are defined as <code>_Bool</code>, <code>1</code> and <code>0</code>, respectively. Therefore, <code>true</code> and <code>false</code> have type <code>int</code> in C. This is likely to change in [[C23 (C standard revision)|C23]] however, whose draft includes changing <code>bool</code>, <code>true</code>, and <code>false</code> to become keywords, and giving <code>true</code> and <code>false</code> the type <code>bool</code>. |
||
* In C it is implementation-defined whether a [[bit field]] of type <code>int</code> is signed or unsigned while in C++ it is always signed to match the underlying type. |
|||
Several of the other differences from the previous section can also be exploited to create code that compiles in both languages but behaves differently. For example, the following function will return different values in C and C++: |
Several of the other differences from the previous section can also be exploited to create code that compiles in both languages but behaves differently. For example, the following function will return different values in C and C++: |
||
< |
<syntaxhighlight lang="C"> |
||
extern int T; |
extern int T; |
||
Line 143: | Line 160: | ||
*/ |
*/ |
||
} |
} |
||
</syntaxhighlight> |
|||
</source> |
|||
This is due to C requiring <code>struct</code> in front of structure tags (and so <code>sizeof(T)</code> refers to the variable), but C++ allowing it to be omitted (and so <code>sizeof(T)</code> refers to the implicit <code>typedef</code>). Beware that the outcome is different when the <code>extern</code> declaration is placed inside the function: then the presence of an identifier with same name in the function scope inhibits the implicit <code>typedef</code> to take effect for C++, and the outcome for C and C++ would be the same. Observe also that the ambiguity in the example above is due to the use of the parenthesis with the <code>sizeof</code> operator. Using <code>sizeof T</code> would expect <code>T</code> to be an expression and not a type, and thus the example would not compile with C++. |
This is due to C requiring <code>struct</code> in front of structure tags (and so <code>sizeof(T)</code> refers to the variable), but C++ allowing it to be omitted (and so <code>sizeof(T)</code> refers to the implicit <code>typedef</code>). Beware that the outcome is different when the <code>extern</code> declaration is placed inside the function: then the presence of an identifier with same name in the function scope inhibits the implicit <code>typedef</code> to take effect for C++, and the outcome for C and C++ would be the same. Observe also that the ambiguity in the example above is due to the use of the parenthesis with the <code>sizeof</code> operator. Using <code>sizeof T</code> would expect <code>T</code> to be an expression and not a type, and thus the example would not compile with C++. |
||
Line 156: | Line 173: | ||
A common practice for [[header file]]s to maintain both C and C++ compatibility is to make its declaration be <code>extern "C"</code> for the scope of the header:<ref>{{cite web|url=http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Fstandlib%2Fref%2Fstdcpplib.htm|title=IBM Knowledge Center|work=ibm.com}}</ref> |
A common practice for [[header file]]s to maintain both C and C++ compatibility is to make its declaration be <code>extern "C"</code> for the scope of the header:<ref>{{cite web|url=http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Fstandlib%2Fref%2Fstdcpplib.htm|title=IBM Knowledge Center|work=ibm.com}}</ref> |
||
< |
<syntaxhighlight lang="c"> |
||
/* Header file foo.h */ |
/* Header file foo.h */ |
||
#ifdef __cplusplus /* If this is a C++ compiler, use C linkage */ |
#ifdef __cplusplus /* If this is a C++ compiler, use C linkage */ |
||
Line 170: | Line 187: | ||
} |
} |
||
#endif |
#endif |
||
</syntaxhighlight> |
|||
</source> |
|||
Differences between C and C++ [[Linkage (software)|linkage]] and calling conventions can also have subtle implications for code that uses [[function pointer]]s. Some compilers will produce non-working code if a function pointer declared <code>extern "C"</code> points to a C++ function that is not declared <code>extern "C"</code>.<ref>{{cite web|url=http://docs.sun.com/source/819-3689/Ch3.Std.html#pgfId-18503 |title=Oracle Documentation |publisher=Docs.sun.com |date |
Differences between C and C++ [[Linkage (software)|linkage]] and calling conventions can also have subtle implications for code that uses [[function pointer]]s. Some compilers will produce non-working code if a function pointer declared <code>extern "C"</code> points to a C++ function that is not declared <code>extern "C"</code>.<ref>{{cite web |url=http://docs.sun.com/source/819-3689/Ch3.Std.html#pgfId-18503 |title=Oracle Documentation |publisher=Docs.sun.com |access-date=18 August 2013 |url-status=live |archive-url=https://web.archive.org/web/20090403134627/http://docs.sun.com/source/819-3689/Ch3.Std.html#pgfId-18503 |archive-date=3 April 2009 |df=dmy-all }}</ref> |
||
For example, the following code: |
For example, the following code: |
||
< |
<syntaxhighlight lang="c" line highlight="2,6"> |
||
void my_function(); |
void my_function(); |
||
extern "C" void foo(void (*fn_ptr)(void)); |
extern "C" void foo(void (*fn_ptr)(void)); |
||
Line 183: | Line 200: | ||
foo(my_function); |
foo(my_function); |
||
} |
} |
||
</syntaxhighlight> |
|||
</source> |
|||
Using [[Sun Microsystems]]' C++ compiler, this produces the following warning: |
Using [[Sun Microsystems]]' C++ compiler, this produces the following warning: |
||
< |
<syntaxhighlight lang="c" highlight="1"> |
||
$ CC -c test.cc |
$ CC -c test.cc |
||
"test.cc", line 6: Warning (Anachronism): Formal argument fn_ptr of type |
"test.cc", line 6: Warning (Anachronism): Formal argument fn_ptr of type |
||
extern "C" void(*)() in call to foo(extern "C" void(*)()) is being passed |
extern "C" void(*)() in call to foo(extern "C" void(*)()) is being passed |
||
void(*)(). |
void(*)(). |
||
</syntaxhighlight> |
|||
</source> |
|||
This is because <code>my_function()</code> is not declared with C linkage and calling conventions, but is being passed to the C function <code>foo()</code>. |
This is because <code>my_function()</code> is not declared with C linkage and calling conventions, but is being passed to the C function <code>foo()</code>. |
||
Line 205: | Line 222: | ||
{{CProLang}} |
{{CProLang}} |
||
{{C++ programming language}} |
|||
{{Use dmy dates|date=January 2015}} |
{{Use dmy dates|date=January 2015}} |
Latest revision as of 23:04, 23 July 2024
The C and C++ programming languages are closely related but have many significant differences. C++ began as a fork of an early, pre-standardized C, and was designed to be mostly source-and-link compatible with C compilers of the time.[1][2] Due to this, development tools for the two languages (such as IDEs and compilers) are often integrated into a single product, with the programmer able to specify C or C++ as their source language.
However, C is not a subset of C++,[3] and nontrivial C programs will not compile as C++ code without modification. Likewise, C++ introduces many features that are not available in C and in practice almost all code written in C++ is not conforming C code. This article, however, focuses on differences that cause conforming C code to be ill-formed C++ code, or to be conforming/well-formed in both languages but to behave differently in C and C++.
Bjarne Stroustrup, the creator of C++, has suggested[4] that the incompatibilities between C and C++ should be reduced as much as possible in order to maximize interoperability between the two languages. Others have argued that since C and C++ are two different languages, compatibility between them is useful but not vital; according to this camp, efforts to reduce incompatibility should not hinder attempts to improve each language in isolation. The official rationale for the 1999 C standard (C99) "endorse[d] the principle of maintaining the largest common subset" between C and C++ "while maintaining a distinction between them and allowing them to evolve separately", and stated that the authors were "content to let C++ be the big and ambitious language."[5]
Several additions of C99 are not supported in the current C++ standard or conflicted with C++ features, such as variable-length arrays, native complex number types and the restrict
type qualifier. On the other hand, C99 reduced some other incompatibilities compared with C89 by incorporating C++ features such as //
comments and mixed declarations and code.[6]
Constructs valid in C but not in C++
[edit]C++ enforces stricter typing rules (no implicit violations of the static type system[1]), and initialization requirements (compile-time enforcement that in-scope variables do not have initialization subverted)[7] than C, and so some valid C code is invalid in C++. A rationale for these is provided in Annex C.1 of the ISO C++ standard.[8]
- One commonly encountered difference is C being more weakly-typed regarding pointers. Specifically, C allows a
void*
pointer to be assigned to any pointer type without a cast, while C++ does not; this idiom appears often in C code usingmalloc
memory allocation,[9] or in the passing of context pointers to the POSIX pthreads API, and other frameworks involving callbacks. For example, the following is valid in C but not C++:void *ptr; /* Implicit conversion from void* to int* */ int *i = ptr;
or similarly:
int *j = malloc(5 * sizeof *j); /* Implicit conversion from void* to int* */
In order to make the code compile as both C and C++, one must use an explicit cast, as follows (with some caveats in both languages[10][11]):
void *ptr; int *i = (int *)ptr; int *j = (int *)malloc(5 * sizeof *j);
- C++ has more complicated rules about pointer assignments that add qualifiers as it allows the assignment of
int **
toconst int *const *
but not the unsafe assignment toconst int **
while C allows neither of those (although compilers will usually only emit a warning). - C++ changes some C standard library functions to add additional overloaded functions with
const
type qualifiers, e.g.strchr
returnschar*
in C, while C++ acts as if there were two overloaded functionsconst char *strchr(const char *)
and achar *strchr(char *)
. In C23 generic selection will be used to make C's behaviour more similar to C++'s.[12] - C++ is also more strict in conversions to enums: ints cannot be implicitly converted to enums as in C. Also, enumeration constants (
enum
enumerators) are always of typeint
in C, whereas they are distinct types in C++ and may have a size different from that ofint
.[needs update] - In C++ a
const
variable must be initialized; in C this is not necessary. - C++ compilers prohibit goto or switch from crossing an initialization, as in the following C99 code:
void fn(void) { goto flack; int i = 1; flack: ; }
- While syntactically valid, a
longjmp()
results in undefined behaviour in C++ if the jumped-over stack frames include objects with nontrivial destructors.[13] The C++ implementation is free to define the behaviour such that destructors would be called. However, this would preclude some uses oflongjmp()
which would otherwise be valid, such as implementation of threads or coroutines switching between separate call stacks withlongjmp()
— when jumping from the lower to the upper call stack in global address space, destructors would be called for every object in the lower call stack. No such issue exists in C. - C allows for multiple tentative definitions of a single global variable in a single translation unit, which is invalid as an ODR violation in C++.
int N; int N = 10;
- In C, declaring a new type with the same name as an existing
struct
,union
orenum
is valid, but it is invalid in C++, because in C,struct
,union
, andenum
types must be indicated as such whenever the type is referenced whereas in C++, all declarations of such types carry the typedef implicitly.enum BOOL {FALSE, TRUE}; typedef int BOOL;
- Non-prototype ("K&R"-style) function declarations are invalid in C++; they are still valid in C until C23,[14][15] although they have been deemed obsolescent since C's original standardization in 1990. (The term "obsolescent" is a defined term in the ISO C standard, meaning a feature that "may be considered for withdrawal in future revisions" of the standard.) Similarly, implicit function declarations (using functions that have not been declared) are not allowed in C++, and have been invalid in C since 1999.
- In C until C23,[16] a function declaration without parameters, e.g.
int foo();
, implies that the parameters are unspecified. Therefore, it is legal to call such a function with one or more arguments, e.g.foo(42, "hello world")
. In contrast, in C++ a function prototype without arguments means that the function takes no arguments, and calling such a function with arguments is ill-formed. In C, the correct way to declare a function that takes no arguments is by using 'void', as inint foo(void);
, which is also valid in C++. Empty function prototypes are a deprecated feature in C99 (as they were in C89). - In both C and C++, one can define nested
struct
types, but the scope is interpreted differently: in C++, a nestedstruct
is defined only within the scope/namespace of the outerstruct
, whereas in C the inner struct is also defined outside the outer struct. - C allows
struct
,union
, andenum
types to be declared in function prototypes, whereas C++ does not.
C99 and C11 added several additional features to C that have not been incorporated into standard C++ as of C++20, such as complex numbers, variable length arrays (complex numbers and variable length arrays are designated as optional extensions in C11), flexible array members, the restrict keyword, array parameter qualifiers, and compound literals.
- Complex arithmetic using the
float complex
anddouble complex
primitive data types was added in the C99 standard, via the_Complex
keyword andcomplex
convenience macro. In C++, complex arithmetic can be performed using the complex number class, but the two methods are not code-compatible. (The standards since C++11 require binary compatibility, however.)[17] - Variable length arrays. This feature leads to possibly non-compile time sizeof operator.[18]
void foo(size_t x, int a[*]); // VLA declaration void foo(size_t x, int a[x]) { printf("%zu\n", sizeof a); // same as sizeof(int*) char s[x * 2]; printf("%zu\n", sizeof s); // will print x*2 }
- The last member of a C99 structure type with more than one member may be a flexible array member, which takes the syntactic form of an array with unspecified length. This serves a purpose similar to variable-length arrays, but VLAs cannot appear in type definitions, and unlike VLAs, flexible array members have no defined size. ISO C++ has no such feature. Example:
struct X { int n, m; char bytes[]; }
- The
restrict
type qualifier defined in C99 was not included in the C++03 standard, but most mainstream compilers such as the GNU Compiler Collection,[19] Microsoft Visual C++, and Intel C++ Compiler provide similar functionality as an extension. - Array parameter qualifiers in functions are supported in C but not C++.
int foo(int a[const]); // equivalent to int *const a int bar(char s[static 5]); // annotates that s is at least 5 chars long
- The functionality of compound literals in C is generalized to both built-in and user-defined types by the list initialization syntax of C++11, although with some syntactic and semantic differences.
struct X a = (struct X){4, 6}; // The equivalent in C++ would be X{4, 6}. The C syntactic form used in C99 is supported as an extension in the GCC and Clang C++ compilers. foo(&(struct X){4, 6}); // The object is allocated in the stack and its address can be passed to a function. This is not supported in C++. if (memcmp(d, (int []){8, 6, 7, 5, 3, 0, 9}, n) == 0) {} // The equivalent in C++ would be using digits = int []; if (memcmp(d, digits{8, 6, 7, 5, 3, 0, 9}, n) == 0) {}
- Designated initializers for arrays are valid only in C:
char s[20] = { [0] = 'a', [8] = 'g' }; // allowed in C, not in C++
- Functions that do not return can be annotated using a
noreturn
attribute in C++ whereas C uses a distinct keyword. In C23, the attribute syntax is also supported.[20]
C++ adds numerous additional keywords to support its new features. This renders C code using those keywords for identifiers invalid in C++. For example:
struct template
{
int new;
struct template* class;
};
- is valid C code, but is rejected by a C++ compiler, since the keywords
template
,new
andclass
are reserved.
Constructs that behave differently in C and C++
[edit]There are a few syntactic constructs that are valid in both C and C++ but produce different results in the two languages.
- Character literals such as
'a'
are of typeint
in C and of typechar
in C++, which means thatsizeof 'a'
will generally give different results in the two languages: in C++, it will be1
, while in C it will besizeof(int)
. As another consequence of this type difference, in C,'a'
will always be a signed expression, regardless of whether or notchar
is a signed or unsigned type, whereas for C++ this is compiler implementation specific. - C++ assigns internal linkage to namespace-scoped
const
variables unless they are explicitly declaredextern
, unlike C in whichextern
is the default for all file-scoped entities. In practice this does not lead to silent semantic changes between identical C and C++ code but instead will lead to a compile-time or linkage error. - In C, use of inline functions requires manually adding a prototype declaration of the function using the extern keyword in exactly one translation unit to ensure a non-inlined version is linked in, whereas C++ handles this automatically. In more detail, C distinguishes two kinds of definitions of
inline
functions: ordinary external definitions (whereextern
is explicitly used) and inline definitions. C++, on the other hand, provides only inline definitions for inline functions. In C, an inline definition is similar to an internal (i.e. static) one, in that it can coexist in the same program with one external definition and any number of internal and inline definitions of the same function in other translation units, all of which can differ. This is a separate consideration from the linkage of the function, but not an independent one. C compilers are afforded the discretion to choose between using inline and external definitions of the same function when both are visible. C++, however, requires that if a function with external linkage is declaredinline
in any translation unit then it must be so declared (and therefore also defined) in every translation unit where it is used, and that all the definitions of that function be identical, following the ODR. Static inline functions behave identically in C and C++. - Both C99 and C++ have a Boolean type
bool
with constantstrue
andfalse
, but they are defined differently. In C++,bool
is a built-in type and a reserved keyword. In C99, a new keyword,_Bool
, is introduced as the new Boolean type. The headerstdbool.h
provides macrosbool
,true
andfalse
that are defined as_Bool
,1
and0
, respectively. Therefore,true
andfalse
have typeint
in C. This is likely to change in C23 however, whose draft includes changingbool
,true
, andfalse
to become keywords, and givingtrue
andfalse
the typebool
. - In C it is implementation-defined whether a bit field of type
int
is signed or unsigned while in C++ it is always signed to match the underlying type.
Several of the other differences from the previous section can also be exploited to create code that compiles in both languages but behaves differently. For example, the following function will return different values in C and C++:
extern int T;
int size(void)
{
struct T { int i; int j; };
return sizeof(T);
/* C: return sizeof(int)
* C++: return sizeof(struct T)
*/
}
This is due to C requiring struct
in front of structure tags (and so sizeof(T)
refers to the variable), but C++ allowing it to be omitted (and so sizeof(T)
refers to the implicit typedef
). Beware that the outcome is different when the extern
declaration is placed inside the function: then the presence of an identifier with same name in the function scope inhibits the implicit typedef
to take effect for C++, and the outcome for C and C++ would be the same. Observe also that the ambiguity in the example above is due to the use of the parenthesis with the sizeof
operator. Using sizeof T
would expect T
to be an expression and not a type, and thus the example would not compile with C++.
Linking C and C++ code
[edit]While C and C++ maintain a large degree of source compatibility, the object files their respective compilers produce can have important differences that manifest themselves when intermixing C and C++ code. Notably:
- C compilers do not name mangle symbols in the way that C++ compilers do.[21]
- Depending on the compiler and architecture, it also may be the case that calling conventions differ between the two languages.
For these reasons, for C++ code to call a C function foo()
, the C++ code must prototype foo()
with extern "C"
. Likewise, for C code to call a C++ function bar()
, the C++ code for bar()
must be declared with extern "C"
.
A common practice for header files to maintain both C and C++ compatibility is to make its declaration be extern "C"
for the scope of the header:[22]
/* Header file foo.h */
#ifdef __cplusplus /* If this is a C++ compiler, use C linkage */
extern "C" {
#endif
/* These functions get C linkage */
void foo();
struct bar { /* ... */ };
#ifdef __cplusplus /* If this is a C++ compiler, end C linkage */
}
#endif
Differences between C and C++ linkage and calling conventions can also have subtle implications for code that uses function pointers. Some compilers will produce non-working code if a function pointer declared extern "C"
points to a C++ function that is not declared extern "C"
.[23]
For example, the following code:
void my_function();
extern "C" void foo(void (*fn_ptr)(void));
void bar()
{
foo(my_function);
}
Using Sun Microsystems' C++ compiler, this produces the following warning:
$ CC -c test.cc
"test.cc", line 6: Warning (Anachronism): Formal argument fn_ptr of type
extern "C" void(*)() in call to foo(extern "C" void(*)()) is being passed
void(*)().
This is because my_function()
is not declared with C linkage and calling conventions, but is being passed to the C function foo()
.
References
[edit]- ^ a b Stroustrup, Bjarne. "An Overview of the C++ Programming Language in The Handbook of Object Technology (Editor: Saba Zamir). CRC Press LLC, Boca Raton. 1999. ISBN 0-8493-3135-8" (PDF). p. 4. Archived (PDF) from the original on 16 August 2012. Retrieved 12 August 2009.
- ^ B.Stroustrup. "C and C++: Siblings. The C/C++ Users Journal. July 2002" (PDF). Retrieved 17 March 2019.
- ^ "Bjarne Stroustrup's FAQ – Is C a subset of C++?". Retrieved 22 September 2019.
- ^ B. Stroustrup. "C and C++: A Case for Compatibility. The C/C++ Users Journal. August 2002" (PDF). Archived (PDF) from the original on 22 July 2012. Retrieved 18 August 2013.
- ^ Rationale for International Standard—Programming Languages—C Archived 6 June 2016 at the Wayback Machine, revision 5.10 (April 2003).
- ^ "C Dialect Options - Using the GNU Compiler Collection (GCC)". gnu.org. Archived from the original on 26 March 2014.
- ^ "N4659: Working Draft, Standard for Programming Language C++" (PDF). §Annex C.1. Archived (PDF) from the original on 7 December 2017. ("It is invalid to jump past a declaration with explicit or implicit initializer (except across entire block not entered). … With this simple compile-time rule, C++ assures that if an initialized variable is in scope, then it has assuredly been initialized.")
- ^ "N4659: Working Draft, Standard for Programming Language C++" (PDF). §Annex C.1. Archived (PDF) from the original on 7 December 2017.
- ^ "IBM Knowledge Center". ibm.com.
- ^ "FAQ > Casting malloc - Cprogramming.com". faq.cprogramming.com. Archived from the original on 5 April 2007.
- ^ "4.4a — Explicit type conversion (casting)". 16 April 2015. Archived from the original on 25 September 2016.
- ^ "Qualifier-preserving standard library functions, v4" (PDF).
- ^ "longjmp - C++ Reference". www.cplusplus.com. Archived from the original on 19 May 2018.
- ^ "WG14 N2432 : Remove support for function definitions with identifier lists" (PDF).
- ^ "2011 ISO C draft standard" (PDF).
- ^ "WG14 N 2841: No function declarators without prototypes".
- ^ "std::complex - cppreference.com". en.cppreference.com. Archived from the original on 15 July 2017.
- ^ "Incompatibilities Between ISO C and ISO C++". Archived from the original on 9 April 2006.
- ^ Restricted Pointers Archived 6 August 2016 at the Wayback Machine from Using the GNU Compiler Collection (GCC)
- ^ "WG14-N2764 : The noreturn attribute" (PDF). open-std.org. 21 June 2021. Archived (PDF) from the original on 25 December 2022.
- ^ "IBM Knowledge Center". ibm.com.
- ^ "IBM Knowledge Center". ibm.com.
- ^ "Oracle Documentation". Docs.sun.com. Archived from the original on 3 April 2009. Retrieved 18 August 2013.
External links
[edit]- Detailed comparison, sentence by sentence, from a C89 Standard perspective.
- Incompatibilities Between ISO C and ISO C++, David R. Tribble (August 2001).
- Oracle (Sun Microsystems) C++ Migration Guide, section 3.11, Oracle/Sun compiler docs on linkage scope.
- Oracle: Mixing C and C++ Code in the Same Program, overview by Steve Clamage (ANSI C++ Committee chair).