C/C++

C's New Ease of Use and How the Language Compares with C++

C11 adds useful, handy features that match some of the additions to C++. However, key divergences mean that a few C11 features have no counterparts in C++.

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 ("_Atomicparenthesis"), 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 ("_Atomicspace").

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

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!