my-server
← Wiki

Compatibility of C and C++

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. 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++, 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 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."

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 <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.

Constructs valid in C but not in C++

C++ enforces stricter typing rules (no implicit violations of the static type system), and initialization requirements (compile-time enforcement that in-scope variables do not have initialization subverted) 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.

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.

C++ adds numerous additional keywords to support its new features. This renders C code using those keywords for identifiers invalid in C++. For example, the following snippet 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++

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 <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> 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>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.
  • 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 <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 C (since C99) and C++ have a 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 built-in type and a reserved keyword.
  • In C99, a new keyword, <code>_Bool</code>, is introduced as a new built-in 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 the type <code>int</code>.
  • In C23 however, <code>bool</code> (and its values <code>true</code> and <code>false</code>) are keywords.
  • C++ has the types <code>char8_t</code>, <code>char16_t</code> and <code>char32_t</code> to encode a single UTF code unit. C23 includes these, but as typedefs to other integer types rather than distinct built-in types, such that their names are not reserved keywords.
  • 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++:

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++.

Linking C and C++ code

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.
  • 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 <code>foo()</code>, the C++ code must prototype <code>foo()</code> with <code>extern "C"</code>. Likewise, for C code to call a C++ function <code>bar()</code>, the C++ code for <code>bar()</code> must be declared with <code>extern "C"</code>.

A common practice for header files to maintain both C and C++ compatibility is to make its declaration be <code>extern "C"</code> for the scope of the header:

In

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 <code>extern "C"</code> points to a C++ function that is not declared <code>extern "C"</code>.

For example, the following code:

Using Sun Microsystems' C++ compiler, this produces the following warning:

This is because <code>myFunction()</code> is not declared with C linkage and calling conventions, but is being passed to the C function <code>foo()</code>.

See also

References

External links