Editor's Forum
That ancient leviathan, Standard C, is stirring in its waters, making noises like it's ready for a change. In December 1997, the C standards committee announced the release of the ISO/IEC CD 9899 Committee Draft (CD) for public review. The CD, also known as C9X (9X meaning some time in the 1990s), has been a long time coming. Standard C hasn't changed much over the years, but numerous proposals for enhancements have come and gone.
For example, a few years ago the C committee was toying with the idea of adding classes to C. We published an article about it, written by one of the main proponents (see "All is Flux" by Bob Jervis, CUJ, October 1994). Frankly, I'm relieved that (at least for now) the C committee has dropped that idea. Adding classes to Standard C might have wrecked its highly desirable compatibility with C++, and thrown us all into confusion. True, classes could make C even more like C++, but only if they had the same semantics as C++ classes, and such an outcome seems unlikely. There are just too many things that could be done differently. For instance, if you read Jervis's article you'll find a proposal for classes without constructors, among other peculiarities. We probably don't need another C/C++ object model, any more than we need two Javas, two Dynamic HTMLs, or two Windows 95s.
C won't get classes, but we still could see it drift away from C++. C has always been the language of choice for efficient, low-level tasks (such as number crunching); the C committee could decide that it was more important to develop these aspects of C than to maintain compatibility with C++. Indeed, C9X hints at such a direction. It includes extensions that emphasize C's role in numerical and embedded applications, and these extensions aren't compatible with the current C++ FDIS (Final Draft Information Standard to read more about the FDIS, see Pete Becker's column in last month's CUJ). C9X specifies a type complex, but since C doesn't have templates, it's not at all like the complex found in the C++ Standard Library. There are C9X extensions that allow a programmer to specify types with exact word sizes. This could be a nice feature, but again, it's incompatible with the current version of C++.
Of course, compatibility is a relative thing. C is relatively compatible with C++ because it is a near subset of C++. C9X diminishes that compatibility somewhat, but even if it's adopted as is, we'll still be able to call C a subset of C++ and keep a straight face. What's more, it's conceivable that C++ might pick up features of C9X that aren't too complex (no pun intended), thus continuing a long tradition of mutual imitation. This tradition has been a boon to C and C++ programmers. The worst thing would be if the C and C++ committees considered their respective languages to be in competition. The only winner in such a battle would be Java. Fortunately, such competition also seems unlikely.
These are interesting times, what with the release of C9X and the C++ FDIS. It's hard to predict how all this standardization business will pan out, but you may be able to participate in the shaping of Standard C. You have until March 3rd to review the CD and submit your comments to the committee. To find out how, visit our website at http://www.cuj.com/news/122397.html.
Marc Briand
Editor-in-Chief