The C community is waking up once again. For years, C has been the stable alternative, the language of choice where performance, precision, and portability count. Want thrills and excitement? Go try your hand at C++. That's where most of the clever new ideas get tried out these days. C++ has reveled in an adolescent vigor because it could depend on C to provide a stable springboard.Now the shoe is on the other foot, at least to some extent. Work on revising the C Standard is commencing two years earlier than required by ISO rules. ISO committee WG14 and ANSI X3J11 both unanimously agreed at their December meeting in Kona, Hawaii on an outline for bringing Standard C more up to date. Even more important, the joint committee agreed on a number of guiding principles for introducing changes to the language. (You'll be reading more about those principles in these pages in the months and years to come.) Closing the gap with C++ ranked very near the top of that list of principles.
A strength of C++, sometimes forgotten, is that it remains largely upward compatible with C. You can always fall back on the older language and still write the "interesting" parts in C++. A weakness of C++, sometimes underestimated, is that it thus feels unconstrained. The sentiment among those standardizing C++ is that it should handle all coding challenges from the world of object-oriented programming, however much they complexify the language.
We self-appointed custodians of Standard C appreciate the real contributions made by C++ to the programmer's toolchest. At the same time, we fear losing "the spirit of C" in our zeal to keep up with the times. Our safety valve is to apply the C++ trick in reverse. We're eager to add classes to C, but probably not templates — polymorphism, but maybe not multiple inheritance. Sure there are times when you need those more advanced features. Maybe those are the times when you should mix in a little C++ code. The rest of the time, let's keep C efficient and conceptually simple.
Bjarne Stroustrup, the developer of C++, has privately expressed concern to me that this new C standardization activity could lead to dueling standards. He rightly fears a civil war between the two most popular programming languages. I certainly don't want to see anything of the sort come to pass. So long as we focus on keeping a large common subset between the two languages, I don't think that it will. For years, the watchword of the C++ standards effort has been, "as close as possible to C, but no closer." Now the watchword of the C standards effort should be, "closer to C++ than you thought possible, but not too close."
P.J. Plauger
pjp@plauger. com