C/C++ Standardization: An Update

If the number of recently published books and magazine articles are any gauge, you'd think the future of C is spelled "C++." To paraphrase Mark Twain, however, reports of C's death are greatly exaggerated. Books and articles aside, C remains a proven, reliable, precisely defined workhorse, still used by many more programmers than C++. Furthermore, use of C continues to grow, especially in internationalization applications, where C is the language of choice.

Since my article "Standard C: A Status Report" (DDJ, August 1991), C has been buffeted on several fronts, including that of internationalization and, most notably, the surge of C++. In this article, I'll look at the current status of Standard C and Draft Standard C++. I'll also examine factors that could affect the future of these languages and discuss what is and is not technically and/or politically feasible.

The ANSI C standard (X3.159-1989) was ratified in December 1989, although technically it was completed a year earlier. An ISO C standard followed, but--except for a number of minor editorial and formatting differences--it was equivalent to that accepted by ANSI. In 1992 the ANSI standard was officially withdrawn, as control of the C standard passed from ANSI to ISO, so that we now have a single standard. The upshot is that C is truly an internationally managed language.

In December 1992, the ISO C committee distributed for balloting an addendum that added several headers and a large group of associated macros, typedefs, and functions--all of which enhance the support for multibyte characters. Some digraphs also were added to overcome readability problems with terminals using the ISO 646 character set. This addendum will likely be approved by the end of 1993.

The ANSI and ISO C committees are now in interpretations mode. Any new development comes through the ISO committee although national committees (such as that from the U.S.) could be authorized to do technical work on ISO's behalf.

There are a number of issues pertaining to internationalization still pending at the ISO level, among them the use of national characters in identifiers. Other issues will surely arise, particularly as we gain experience with existing components of the standard. (It's significant to note that Microsoft's Windows NT uses a 16-bit-based character set, not ASCII. With its extensive multibyte support, C will grow in this direction even further.)

X3J11.1, known informally as the "Numerical C Extensions Group" (NCEG), has issued final drafts of three parts of its technical report. (For background information on NCEG's work, see "Numerical Extensions to C," by Robert Jervis, DDJ, August 1992.) While this report does not have the power of a standard, it nonetheless lays the groundwork for additions to the language. The final report is expected by the end of 1994.

In December 1989, an independent C++ standards effort (X3J16) was launched. It's important to note that the X3J11 C committee declined to take on the job of standardizing C++. Certainly C++ and Standard C have common ancestors, but they were viewed as different languages. For more information on C++ standardization, see "Standard C++: A Status Report" by Dan Saks (special supplement to Dr. Dobb's Journal, December 1992.)

Within the first year or so of deliberation, the committee decided that the C++ standard would be a joint ANSI/ISO effort. Currently, meetings are held jointly, alternating between U.S. and non-U.S. locations, resulting in considerably more international participation than the C standard had in its infancy.

The C++ committee is also inventing much more than did the original Standard C committee. The additions being considered and the set of standard classes that will be defined may well result in the final standard being delayed beyond the current goal of 1996. And don't forget that when the draft standard goes out for public review, the committee must respond in writing to every comment received. This process, which could easily take a couple of years, is repeated until no more substantive changes are made and no appeals are pending. (Standard C went through three cycles.) As a result, a C++ standard isn't going to become official any time soon.

It is important to note that C++ is not a proper superset of Standard C; there are numerous differences. The C++ standards committee has a C Compatibility subcommittee that identifies the incompatibilities and either rationalizes them or suggests changes. ISO JTC1/

SC22 decreed that Standard C and Standard C++ should have no gratuitous differences; but some differences are permitted, meaning that C++ might never be a proper superset of C.

A number of other ANSI and ISO committees are busy defining language bindings for C and C++. Some are also working on language-independent issues--parallel processing, internationalization, language-independent arithmetic, procedure-passing methods, and the like--that will likely have some impact on the C and C++ standards.

We may see a number of possible scenarios played out regarding C and C++, among them:

• Freeze C based on the latest ISO addendum, thereby placing it in maintenance mode. This is quite restrictive in that it ignores the efforts of X3J11.1, doesn't permit further work on internationalization support or the addition of some interesting and useful parts of C++, and doesn't cater to the extensions that will likely be possible (if not mandated) by related standards bodies.
• Extend C, but only in the direction of C++. This is also restrictive because it, too, ignores the efforts of X3J11.1 and doesn't permit further work on internationalization support.
• Extend C in a number of directions, including C++ and internationalization. This isn't restrictive and allows for the efforts of X3J11.1 and other subcommittees to be considered.
• Formally coordinate the C and C++ standards committees with the long-term goal of merging the two languages. The result could be a single language, C++, or, the language C++ with a distinct subset called C.

It's worth noting that some commercial C implementors would much rather extend C "just a little bit more" (for example, adding a complex type rather than defining a complex class) rather than buying into the whole of C++.

The fourth option--making one language--requires that differences between the languages be eliminated completely. Realistically speaking, this is where we are now, except the subset is not a proper subset, and the subset is the responsibility of a separate standards committee.

Because C and C++ are far more similar than different, a more formal synchronization between them would be beneficial if, for no other reason than to reduce the resources required to participate in standards activities.

Synchronization does, however, have its own problems. Currently, the C committees are busy interpreting their standard with an eye on at least some minor additions in the internationalization arena. Meanwhile, the C++ committee is working on its first standard using a specific project proposal endorsed by ANSI and ISO. It's almost certainly a bad idea to derail the current C++ standardization effort to include synchronization with Standard C. The setback in time and inertia would likely produce a lose/lose situation.

The more likely alternative is to wait until the C++ standard is approved before attempting some formal synchronization. Let's say, for argument's sake, that C++ is standardized in 1996. Will Standard C stand still in the interim? Not likely. Will it be extended in the C++ direction only? Again, probably not. In the meantime, if C is extended in ways that are incompatible with C++, synchronization will be even more difficult.

It's all well and good to say that if the C committee wants to extend C, it should be consulting the C++ committee. That's good advice, but the C++ committee has enough to do without other standards bodies bothering them. This isn't to suggest the C++ committee is ignoring outside input; they simply have more interest in their own charter, and rightly so.

Even if it were generally agreed that the future of C is really C++, the transition is problematic. It's one thing to be starting new projects with newly trained people and a new design methodology; it's quite another to have a nontrivial investment in code and training already in place.

The issue of object-oriented design and programming is separable from the language that implements it. While C++ is the commercial leader for OOP technology, in the next decade most of the popular procedural languages will likely also have OOP extensions.

Until a C++ standard is completed, C will probably be extended in the direction of C++ as well as in other ways, some of which will also be picked up by C++. Once the C++ committee has met their original goal, some kind of formal synchronization plan is likely. Certainly informal discussion can, and probably should, occur long before then, but it's unreasonable to expect anything formal until then.

So, is the future of C spelled "C++?" Quite possibly, but not until the end of this decade at least, and maybe never. Formal synchronization will require compromise, and we all know how bloody territorial disputes can get. And while we all might want there to be one way, each of us wants it to be our way.

Just what kind of extensions should we make to C? While you could certainly consider completely new ideas--perhaps adding packed-decimal type or I/O statements--many proven extensions are already in existence. Since the list (and merits) of possible extensions is endless and very subjective, I'll not discuss it further. Instead, I'll identify some obvious and incremental ways in which C could be improved.

A number of small extensions could be made. For example:

• Require float and long-double math libraries.
• Add extra E*value macros for errno (for fopen failures, for example).
• Add I/O primitives such as "get character without terminator" and "get character without echo."
• Add the ability to flush an input stream.
• Add more LC_*macros to setlocale, and more locale machinery in general.
• Add more multibyte library support.
• Include binary integer constants.
• Allow nonconstant expressions in auto aggregate initializers.
• Add new bit-field types (such as char, short, long, enum).

• //-style comments.
• Type-safe linkage (encoding function signature in generated name).
• Declarations at other than the beginning of a block.
• The extended syntax for the first expression in a For loop.
• Functional notation casts.
• Scope resolution operator.
• Extra semantics of const.
• Anonymous unions.
• Stricter compatibility checking of enumerated types.
• Overloaded functions.
• Inline functions.
• Default function arguments.
• Operators new and delete.
• References (although they aren't much use without operator overloading).
• Requirement of a diagnostic on failure to return a value from a nonvoid function.
• Drop support for old-style function declarations and definitions.
• Requirement of a prototype in the scope of a function call.

• More FP/IEEE support.
• Extended initializers.
• Aliasing control via keyword restrict.
• Complex data types and associated libraries.
• Variably sized arrays.
• Extended integer precision
• Data-parallel constructs.

Copyright © 1993, Dr. Dobb's Journal