TheC andC++programming languages are closely related but have many significant differences. C++ began as afork 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 asIDEs andcompilers) are often integrated into a single product, with the programmer able to specify C or C++ as their source language.
However, C isnot asubset 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 asvariable-length arrays, nativecomplex number types and therestricttype 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]
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]
void* pointer to be assigned to any pointer type without a cast, while C++ does not; thisidiom appears often in C code usingmalloc memory allocation,[9] or in the passing of context pointers to the POSIXpthreads API, and other frameworks involvingcallbacks. 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]
void*ptr;int*i=(int*)ptr;int*j=(int*)malloc(5*sizeof*j);
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).consttype 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 *). InC23 generic selection is used to make C's behaviour more similar to C++'s.[11]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]const variable must be initialized; in C this is not necessary.voidfn(void){gotoflack;inti=1;flack:;}
longjmp() results in undefined behaviour in C++ if the jumped-overstack frames include objects with nontrivial destructors.[12] 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 ofthreads orcoroutines 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.intN;intN=10;
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 thetypedef implicitly.enumBOOL{FALSE,TRUE};typedefintBOOL;
int foo();, implies that the parameters are unspecified. Therefore, it is legal to call such a function with one or morearguments, 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).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.struct,union, andenum types to be declared in function prototypes, whereas C++ does not.C99 andC11 added several additional features to C that have not been incorporated into standard C++ as ofC++20, such as complex numbers, variable length arrays (complex numbers and variable length arrays are designated as optional extensions in C11),flexible array members, therestrict keyword, array parameter qualifiers, andcompound literals.
float complex anddouble complex primitive data types was added in theC99 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 sinceC++11 require binary compatibility, however.)[16]voidfoo(size_tx,inta[*]);// VLA declarationvoidfoo(size_tx,inta[x]){printf("%zu\n",sizeofa);// same as sizeof(int*)chars[x*2];printf("%zu\n",sizeofs);// will print x*2}
structX{intn,m;charbytes[];}
restricttype qualifier defined in C99 was not included in the C++03 standard, but most mainstream compilers such as theGNU Compiler Collection,[18]Microsoft Visual C++, andIntel C++ Compiler provide similar functionality as an extension.intfoo(inta[const]);// equivalent to int *const aintbar(chars[static5]);// annotates that s is at least 5 chars long
structXa=(structX){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(&(structX){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) {}
chars[20]={[0]='a',[8]='g'};// allowed in C, not in C++
noreturnattribute in C++ whereas C uses a distinct keyword. In C23, the attribute syntax is also supported.[19]C++ adds numerous additional keywords to support its new features. This renders C code using those keywords for identifiers invalid in C++. For example:
structtemplate{intnew;structtemplate*class;};
template,new andclass are reserved.There are a few syntactic constructs that are valid in both C and C++ but produce different results in the two languages.
'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.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.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 thelinkage 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++.bool with constantstrue andfalse, but they are defined differently. In C++,bool is abuilt-in type and areserved 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 inC23 however, whose draft includes changingbool,true, andfalse to become keywords, and givingtrue andfalse the typebool.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++:
externintT;intsize(void){structT{inti;intj;};returnsizeof(T);/* C: return sizeof(int) * C++: return sizeof(struct T) */}
This is due to C requiringstruct in front of structure tags (and sosizeof(T) refers to the variable), but C++ allowing it to be omitted (and sosizeof(T) refers to the implicittypedef). Beware that the outcome is different when theextern declaration is placed inside the function: then the presence of an identifier with same name in the function scope inhibits the implicittypedef 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 thesizeof operator. Usingsizeof T would expectT to be an expression and not a type, and thus the example would not compile with C++.
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:
For these reasons, for C++ code to call a C functionfoo(), the C++ code mustprototypefoo() withextern "C". Likewise, for C code to call a C++ functionbar(), the C++ code forbar() must be declared withextern "C".
A common practice forheader files to maintain both C and C++ compatibility is to make its declaration beextern "C" for the scope of the header:[21]
/* Header file foo.h */#ifdef __cplusplus/* If this is a C++ compiler, use C linkage */extern"C"{#endif/* These functions get C linkage */voidfoo();structbar{/* ... */};#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 usesfunction pointers. Some compilers will produce non-working code if a function pointer declaredextern "C" points to a C++ function that is not declaredextern "C".[22]
For example, the following code:
voidmy_function();extern"C"voidfoo(void(*fn_ptr)(void));voidbar(){foo(my_function);}
UsingSun Microsystems' C++ compiler, this produces the following warning:
$CC-ctest.cc"test.cc",line6:Warning(Anachronism):Formalargumentfn_ptroftypeextern"C"void(*)()incalltofoo(extern"C"void(*)())isbeingpassedvoid(*)().
This is becausemy_function() is not declared with C linkage and calling conventions, but is being passed to the C functionfoo().
| Features | |||||
|---|---|---|---|---|---|
| Standard library |
| ||||
| Compilers | |||||
| IDEs | |||||
| Comparison with other languages | |||||
| Descendant languages | |||||
| Designer | |||||
| Features | |
|---|---|
| Standard Library | |
| Ideas | |
| Compilers | |
| IDEs | |
| Superset languages | |
| Dialects | |
| Relative to other languages | |
| People | |
