Channels ▼



Compatibility with C++

Compatibility with the evolving standard for C++ was a high priority, and a serious challenge, because both standards were completed in the fourth quarter of 2011.

All the new features described in this ease-of-use article can be used in a C11 program, or a C++11 program, with all the same semantics (except, of course, for the type-generic macro).

Last month's article, The New C Standard Explored, described the C11 Annexes K and L (bounds-checking interfaces and analyzability), both of which are not part of C++11. However, the Annex K library is widely available from C++ environments that provide additional libraries for use by the C++ application; certainly Microsoft's Visual Studio has been in this category for several years.

The first article in this series, C Finally Gets a New Standard, covers several compatibility challenges. I've been told by people whose expertise I respect that when you incorporate multithreading into your design, you should put all the threading control into the C++ components, or alternatively, put all the threading control into the C components. A mix-and-match approach to the threading controls raises serious issues. And if the app contains both C and C++ components, there are other (unrelated) good reasons to make the main program a C++ program (initialization of statics, setting up the exception-handling mechanism, etc.). A further consideration is that some compilation environments are fairly close to the C++11 standard for multithreading, where the C11 implementation support might be lagging.

However, with regard to accessing atomic data, the compatibility situation is somewhat more favorable. Depending upon your compiler-and-library environment, you should fairly soon be able to use the named atomic_* basic atomic types in both C11 and C++11. Somewhat more ambitiously, you could use the _Atomic(T) syntax ("_Atomic parenthesis"), and if your C++11 environment doesn't already support this syntax, you could create your own compatibility header containing this definition:

 #define _Atomic(T) atomic<T> 

However, I'm uncertain as to when, or whether, any particular C11 implementation will support the full type-qualifier syntax of _Atomic T ("_Atomic space").

I'm just about ready to summarize the compatibility situation, but first some discussion about conformance testing and optional subsets. From the very beginning of the C standards process (going back to the 1980s), the marketplace for C compilers has been attentive to, and concerned about, the various agencies and processes for formal certification of conformance to the ISO/IEC C standard. Even now in the third decade of successive C standards, a formal certification process is provided by The Open Group for POSIX operating systems, which requires a C compiler. By contrast, there has never yet been a formal certification for C++ compilers; it's probably true that no commercial C++ compiler has ever fully conformed to any ISO/IEC C++ standard.

Given this greater attention to conformance details, it's worth noting that the C11 standard has identified eight different portions of the standard as optional: variable length arrays (VLAs), complex types, IEC 60559 (IEEE) floating-point (Annex F), IEEE complex (Annex G), bounds-checking interfaces (Annex K), analyzability (Annex L), multithreading, and atomic. A compiler could conform to C11 and provide all of these, or none of these, or some portion of these. The minimum requirement of C11 is, of course, to provide none of these. The message from the marketplace, or so it seems to me, is that C99 imposed a number of requirements that were needed only by small portions of the marketplace (what some on the committee referred to as "boutique" markets).

I'll conclude with a table that describes the C/C++ compatibility issues of these eight optional C11 features:

C11 Features C++ Compatibility Issues

1. Variable length arrays (VLAs)

Will never be part of a C++ standard

2. Complex types <complex.h>

User program can be compatible, with effort

3. IEC 60559 floating-point arithmetic (Annex F)

Could be provided by a C++ environment,
but not required

4. IEC 60559 complex arithmetic (Annex G)

Could be provided by a C++ environment,
but not required

5. Bounds-checking interfaces (Annex K)

Could be provided by a C++ environment,
but not required

6. Analyzability (Annex L)

Could be provided by a C++ environment,
but not required

7. Multithreading <threads.h>

Choose C11 or C++11; don't mix

8. Atomic primitives and types <stdatomic.h>

User program can be compatible, with effort

As you see, while there is a lot of the language that has been made identical to C++, C is not a subset of C++.

Note: C11 and C++11 are available from the ANSI store:

For C11, go to

For C++11, go to

Each costs $30 USD for PDF. The whole process takes only a few minutes.


Related Reading

C Finally Gets A New Standard

The New C Standard Explored

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

