Embedded C++ is 2-1/2 years old and going strong. But that doesn't necessarily make it a serious candidate for formal standardization.
It's been about two years since I wrote about Embedded C++ (or EC++ for short) in these pages. (See "Embedded C++," by P.J. Plauger, CUJ, February 1997.) At that time, EC++ was purely a de facto industry standard, with no apparent aspirations to achieve more formal status. It's a small but important point that the article I wrote was in addition to this regular column I've been contributing for over a decade. The theme of every installment of this column has been C or C++ as standardized by either ANSI or ISO. I'm not in a hurry to wander too far afield from that theme.
I'll cut to the chase and tell you that EC++ is not currently a candidate for standardization within ANSI or ISO. But it came close — close enough that I feel it appropriate to report here what has happened over the past year or so. Moreover, the side effects of the effort to begin standardizing EC++ are interesting in their own right. They can have implications, in the years to come, far more profound than whether or not we ever make EC++ more than just another industry standard.
But first a bit of history, to put matters in perspective.
Standardizing C++
The effort to standardize the C++ programming language proper began way back in 1989. At that time, the C standardization effort was just wrapping up. We began working on C in 1983, developed an informal public review draft by early 1985, and then spent four more years wrestling with politics and bureaucracy far more than with any serious alterations to the C language proper. The folks who met in Washington, D.C. in the summer of 1989, to begin standardizing C++, were convinced they could do a faster and better job.
By that time, C++ was really beginning to boom in popularity. The Annotated Reference Manual (or ARM, for short), by Ellis and Stroustrup, was just out. It provided a comprehensive, if not always precise, definition of C++ as it had evolved to date. With the ARM came a sense that C++ was an experiment nearing completion. Many companies wanted the stability of a formal standard before they invested any more heavily in projects based on C++. Besides, many C++ adherents felt that if C was important enough to warrant standardization, then C++ certainly deserved the same treatment.
Thus was born the ANSI-authorized committee X3J16, the C++ analog to the older C committee X3J11. It began meeting three times a year, starting in early 1990. It was soon joined by WG21, the ISO working group analogous to C's WG14. X3J11 and WG14 had met four times a year while actively developing the C Standard, but that was before the days of nearly universal email. X3J16 and WG21 were convinced they could do most of their work between meetings, through group participation on email reflectors, thus telescoping considerably the entire standards-development process.
There were a few loose ends, of course. The ARM made mention of a couple of desirable language features that were not yet spelled out in detail. Bjarne Stroustrup felt strongly that his language should not be frozen until the committee fleshed out the details of exceptions and templates. And the ARM really didn't say much about iostreams, or any other library features that were often associated with C++. And maybe the committee should consider a few other extensions, so long as none of them were really big. Still, there was no excuse for stretching the standardization process out over six years, the way X3J11 and WG14 ended up doing.
Instead, it took nine years to standardize C++.
I measure both times from the first organizational meeting to formal approval, by either ANSI or ISO. This includes a certain amount of bureaucratic dead time at either end. But however you slice it, the C++ Standard involved a lot more invention, over a far longer period of time, than the C Standard indulged in. And substantive changes were being approved until literally minutes before the C++ standard froze, in November 1997.
I've discussed the result of that ambitious effort, in these pages and in other venues, on many occasions. Standard C++ is a large language, with many inventions that are only now being properly tested. Templates, in particular, have proved to be a whole 'nother language superimposed atop traditional C++. The accompanying library (the focus of much of my professional efforts) grew from a vestigial addition to the Standard C library to a truly massive — and often powerful — collection of templates, classes, and functions. Standard C++ is not your father's cfront preprocessor.
The committees were not indiscriminate. A few of us tried on several occasions to steer the library design in certain directions, only to be overruled by strong majorities. The committees favored power and completeness over economy of concepts and compactness. Where the C committees were arguably dominated by implementors of compilers for embedded systems, the C++ committees were clearly dominated by users working on desktop systems. The vision was consistent, if not universally held.
History of EC++
I recite this history to underscore several of the factors that led to the formation of Embedded C++. It began with an organizational meeting in Tokyo, in November 1995. Fujitsu, Hitachi, NEC, and Toshiba are the heavy hitters in the embedded marketplace in Japan. All four companies were facing problems bringing C++ to their customers. The standard was running late, the language and library were getting big, and little attention was being paid to the needs of embedded programmers. Thus, this group of industry heavies decided to specify a subset of the emerging C++ Standard that would avoid the overheads, not to mention the untested new features, of draft Standard C++.
It took about a year, but they came through. By September 1996, I was able to describe the work of the Embedded C++ Technical Committee at the Embedded Systems Conference in San Jose. EC++ was indeed a pretty pure subset of draft Standard C++, but the omissions are often perceived as draconian. Gone are templates, exceptions, run-time type identification, multiple inheritance, and a host of lesser additions to C++ fleshed out over the previous six years of standardization. The library looks more like the early 1994 draft, shorn of all templates and exceptions.
I immediately proceeded to write the library mandated by the Technical Specification. Others doctored compilers and C++ parsers to enforce the specified subset. EC++ quickly established a niche for itself as a commercial product. Today, you will find upwards of a dozen companies offering some degree of commercial support for EC++ compilers, libraries, training, and related tools and services.
Any effort to subset a language, particularly a language still being developed, is bound to stimulate controversy, by its very nature. Nothing was added to C++ during the standardization process purely on a whim. Stroustrup and others were quick to defend every feature of Standard C++ as a necessity, at least for some significant subset of programmers. Needless to say, the advent of EC++ was not universally applauded.
The EC++ Technical Committee supplies a rationale to accompany their Technical Specification. It gives reasons for each of the design decisions. At the risk of oversimplifying, I'll lump most of the reasons into three broad categories:
1) The feature adds significant overhead, in either code size or execution time, which is not repaid in most embedded applications.
2) The feature is sufficiently new that it is not widely available, and not worth waiting for in most embedded applications.
3) The feature adds complexity to C++ which is not repaid in improved programming power in most embedded applications.
Critics of EC++ grudgingly admit that the first category may be a justification for omitting a feature. They argue, however, that developers are better employed adding optimizations to a full implementation of C++, so that it eventually achieves adequate performance. Popularizing a subset dictated by the current state of the art of compiler technology, they argue, can only be pernicious in the long run.
Critics have almost no truck at all with the second and third categories. They consider the second a sop to lazy implementors, who are simply looking for excuses not to bring lagging compilers up to snuff. They consider the third at best to be a sop to lazy programmers, who are simply looking for excuses not to bring lagging skills up to snuff. At worst, they consider the last category to reflect a condescending attitude toward programmers on the part of project managers.
As always, I personally believe that the truth lies somewhere in between. I agree that compiler technology can and should be improved to deal with some of the challenges imposed by the final C++ Standard. But the real world demands solutions now. Not everyone can wait through several years of experimentation to deliver efficient products. Certainly not programmers of embedded systems. It is a legitimate practice, with ample precedent, to offer nonstandard dialects that avoid performance problems.
It is easy to accuse implementors, programmers, and managers of having nefarious motives. It may even be true in some cases. But mostly this tactic smacks of blaming the victims. Many C++ compilers in use today will require a major investment to incorporate all the inventions put into Standard C++ over the past decade. A compiler that is perfectly usable for embedded programming should not be stigmatized, or kept off the market, or left unused, because it lacks all the latest features. It is a legitimate response of compiler vendors to seek credibility for the technology in hand, particularly if it is indeed usable by their principal customers.
Passing the Buck
The tension between full C++ and EC++ is thus inevitable. It also creates an inevitable force on EC++, to become ever bigger and more comprehensive. From the moment the Technical Specification was published, people began asking the EC++ Technical Committee to add this favorite feature or that one that the Committee had chosen to omit. (When was the last time you heard anyone request that a feature be removed from a programming language? The last one I remember was the ALTER verb in COBOL 60.)
Japanese committees tend to do nothing in a hurry. They do even less without a clear consensus of all parties involved. In this case, it was very hard for the EC++ Technical Committee to know what to do. All critics of EC++ wanted the language to get bigger. Even people who basically liked the dialect were inclined to add this bit or the other. Moreover, C++ compilers in the US tend, to this day, to be more complete than those used for embedded programming in Japan. It is hard to explain to someone with a reasonably complete compiler why certain features should be turned off, particularly those that are "weightless" — having no effect on code size or speed.
But adding features, any features at all, to EC++ would have two pernicious effects. The first would be an added burden on all those Japanese compiler vendors. Remember that many features were omitted simply because they were not widely implemented. The second would be a loss of stability. Remember that EC++ was in part a reaction to the prolonged and continual change in the draft C++ Standard. If EC++ were to be altered in any significant way, it would no longer be seen as an island of stability.
After about a year of fending off change, the EC++ Technical Committee did what any good committee does. (And I say this with all due respect for their motives and goals.) They decided to pass the buck. Specifically, they requested the Japanese standards delegation to submit a proposal to ISO. WG21, and presumably J16 (the new name for X3J16), should take over standardization of EC++. If that meant adding significantly to the subset, so be it. In any event, the tough decisions would be made by an international committee of experts.
Equally important — and here I am interpolating motivations in the absence of direct evidence — anything a standards committee does takes time. If WG21 were to take the EC++ Technical Specification and turn it into standardese as quickly as possible, at least two years would doubtless elapse before any formal change came down the pike. Meanwhile, EC++ would enjoy a period of further stability, and various compiler vendors would have more time to catch up with current technology. (It is no longer necessary for every compiler vendor to develop a full-bore template preprocessor. You can license an excellent C++ front end from Edison Design Group, as dozens of other companies have already done. But even adding a new front end to an existing compiler takes time.)
Whatever the possible motivations, the observable fact is that the Japanese delegation submitted such a request at the joint WG21/J16 meeting in Nice, held in March 1998. This was the first meeting after the C++ Standard froze, and final balloting was still under way, so the committees had little to do. But they did take the time to discuss the Japanese proposal. Specifically, the request was for the committees to produce a Technical Report describing EC++, which is rather less than an obligatory international standard but still rather more than a de facto industry standard.
By ISO rules, five nations have to agree to participate in the development of a New Project (NP) or it won't even get off the ground. The committees didn't want to vote on a potential NP until they were sure of adequate support. On the other hand, it's rather difficult for the experts representing various countries to drum up support without some evidence that the C++ committees were interested in tackling the project. A chicken-and-egg deadlock.
So I pushed for a non-binding straw vote, at the March meeting, to indicate the degree of support within WG21 and J16 for work on standardizing EC++. To get even that vote, I had to agree to a watering down. The actual vote was to show interest in working on C++ for embedded systems and other performance issues. The straw vote nevertheless revealed strong support for pursuing the matter.
The Buck Stops
Nothing much happened for the next half year. Yes, WG21 set up an email reflector to deal with performance issues, but it saw essentially no traffic. Brendan Kehoe, of Cygnus Solutions, agreed to lead the effort in developing an NP to reflect the March 1998 proposal from Japan. He set up yet another reflector at Cygnus, but it mostly dealt with the use of Project Gnu software in embedded applications.
Just days before the October 1998 meeting in Santa Cruz, California, Kehoe posted a brief outline of an NP. Conspicuously absent were the words "embedded" and "subset." At the Santa Cruz meeting, it soon became clear that support for actually standardizing any subset of C++, for embedded programming or any other purpose, was practically nonexistent. Instead, the NP started shaping up as a catch-all vechicle for an assortment of Technical Reports loosely related to the overall theme of performance.
Subsetting suffered a particularly interesting sea change. (No pun intended.) It got subsumed under the amusing euphemism, "user-directed optimization." In plain English, the idea is to require that a C++ compiler support the full language and library, plus a set of option switches. A programmer can select the set of options, each of which may turn on a non-standard subset, to suit his or her fancy. Presumably, the Technical Report would describe the potential benefit of each option. And presumably, compiler vendors would feel pressure to offer all the specified options — and make sure they work in arbitrary combinations.
My cynical view is that a set of, say, six subsetting options is much less threatening than one well tuned subset. Six Boolean compiler switches makes for 64 subsets, no one of which is favored per se. That's a safer bet than endorsing good 'ol 0x2A as a particularly felicitous combination of options. But remember, I am a cynic in such matters.
The bottom line is that WG21 did indeed vote out an NP, which they have submitted to their ISO betters for approval. It calls for producing a Technical Report that discusses performance issues in general, the needs of embedded programmers tangentially, and the idea of subsetting C++ not at all. I'm sure it will be approved and I'm sure it will attract useful contributions from various C++ experts.
It's just not going to standardize EC++, as the Japanese originally requested.
The bad news, to me, is not the bottom line. I expected that. Rather, it's how the decision was arrived at. To explain why I feel that way, here's another snippet of standards history. When WG21 joined X3J16, already in progress, the two committees worked out very carefully how to cooperate. X3J16 was officially ceding its power to WG21, yet it was supplying the vast majority of technical experts, whose hard work would eventually yield the C++ Standard. The potential for friction and hard feelings was very real.
So the committees agreed to a scheme where X3J16 was "first among equals." All technical votes would take place in committee of the whole, as joint sessions of the two committees. Straw votes would first determine whether clear consensus existed before any formal votes were taken. All resolutions would be reduced to writing no later than the night before a formal vote, a clear necessity for non-native English speakers and delegations that cannot cover all the parallel sessions. Each formal vote would then be taken first within X3J16. The International Representative from X3J16 would then vote the US position on the WG21 vote that immediately followed. The US still got only one vote, but if it differed from the WG21 majority, both committees would reconsider the motion, in the hopes of achieving better consensus.
Indeed, the two committees followed this practice religiously for all the years spent developing the C++ Standard. They reconsidered several important votes where the US position was in the minority (to good effect, I might add). And they preached the value of this religion to other standards efforts. X3J11 and WG14 adopted this modus operandi for revising the C Standard, in fact.
All that went out the window at the Santa Cruz meeting. No formal vote ever occurred, or was solicited within J16. Instead, WG21 met separately to discuss and vote on the NP. (The US delegation voted in favor.) No rationale was advanced for treating this vote as unusual, so presumably it represents a fundamental change in procedures. The US is no longer first among equals. At the moment, it's not even clear whether voting rights mean anything at all within J16. Since my company pays to send three delegates to each J16 meeting, I'm understandably peeved at this point. (I have filed a protest, for what it's worth.)
Conclusion
But back to EC++. The good news is that the EC++ Technical Committee seems to have put a good spin on the outcome. I attended their most recent international meeting (held in English) in Tokyo last November. There, the Committee announced that they were content to wait and see what the proposed Technical Report would yield by way of advice. Perhaps it would reinforce the decisions that went into EC++, or perhaps it would suggest new and better ways to optimize C++ for embedded systems. In either case, the Committee was content to leave EC++ unchanged while waiting for further information from WG21.
And that's fine with me. EC++ has been stable for over two years now. It bids fair to be stable for at least another two years. I'm happily licensing libraries to compiler vendors. I'm also happy to report that nine different vendors gave presentations on EC++ products at the meeting in Tokyo. People can argue all they want about how C++ should be used in embedded systems. Meanwhile, some of us are getting work done.
P.J. Plauger is Senior Editor of C/C++ Users Journal and President of Dinkumware, Ltd. He is the author of the Standard C++ Library shipped with Microsoft's Visual C++, v5.0. For eight years, he served as convener of the ISO C standards committee, WG14. He remains active on the C++ committee, J16. His latest books are The Draft Standard C++ Library, Programming on Purpose (three volumes), and Standard C (with Jim Brodie), all published by Prentice-Hall. You can reach him at pjp@plauger.com.