Date:April 7, 2003
Reply to:Greg Comeau
Comeau Computing
comeau@comeaucomputing.com, comeaucomputing@gmail.com
URL:http://www.comeaucomputing.com/iso/promises.html

Serious Promises and Standard C++

  1. Introduction

    We made a serious promise by voting in and establishing Standard C++, recalling that it was voted in with unanimous approval. However, document N1426[1] offers a discussion leading to the choice of two recommendations: (1) completely remove export capability from Standard C++ or (2) make it a non-required feature. A number of committee members are not in favor of either of these choices for a number of reasons. Therefore, in this document, I would like to outline why there is disagreement with such recommendations.

    I would also like to offer details on what I consider to be overstated arguments expressed in N1426.

    I'd like to mention some general information and thoughts first though.

  2. The Cost of Standardization

    It is fair to make the following statements:

    In other words, "There Ain't No Such Thing As A Free Lunch." As such, producing Standard C++ and TC1 has easily cost us 10's of millions of dollars. Participants involved in Standard C++ include not only a "Who's Who?" of compiler and library vendors and implementors, but just as important, participants have always included users, consultants, trainers, and application developers of the C++ community. These groups span an impressive list of internationally known companies that anybody, even if they were not C++ or computer savvy persons, would know of and respect. The committee also reflects an impressive list of talent and skills in many areas of computing, science, engineering and business, among others.

    In D&E[2], Stroustrup lays out, in excruciating pain, the criteria he used while designing C++, and also which the C++ committee used. It's clear that standardizing C++ was and still is a serious issue. Said criteria was approached cautiously and with thought, as any responsible group would do. After all, we owed it to ourselves and the community to do so. Even despite committee constraints, there were lengthy debates which produced a standard with the reasonable result of many well thought out engineering compromises. Of course, it would be naive to say that we achieved perfection, and in fact, a number of problems exist.

  3. Many Problem Areas

    Whereas some committees for other languages stuck strongly with premises such as codifying existing practice, the C++ committee did not. The result was a number of new features. A ramification of that approach was that "features" such as look-up, which were already at their breaking point, were pushed even further. However, the possibility of broadening the girth of C++ was desired (and still is in many areas), sought out, debated and mostly achieved. And so therefore, C++ became even more generally useful as a result of standardization.

    During the time frame of the C++ standardization process, the 1990's, some software developers felt that C++ was too large and too complex for them to use. Some, therefore, completely refused, and still refuse, to use C++. Still others felt is was necessary for whole other languages to be invented, for the same reasons. Consider, for instance, the technical and political aspects of Java.

    Oddly, many of these so-called "simpler" languages or simpler approaches borrow much from C++. Even those developers who use C++ realize that although there is much power they are capable of achieving, it's also true that C++ is not the simplest language to use. There are many C++ features that people find hard to learn and understand.

    Here are some of those complex features, in no particular order:

    Take note that many of these issues are template based, or can involve templates -- for instance, overloading is already complicated, and adding template considerations stresses that complication even further.

    In many cases, authors and trainers completely avoid such topics. In other cases, whole chapters of books are dedicated to explaining these features. In still other cases, whole books have even been written about some of the above features, such as exception handling, iostreams, and templates, without even covering all aspects of the feature.

    These are all completely core C++ issues, yet they are also often misperceived and misunderstood. Granted, there can sometimes be understanding at a basic level, but more involved usage hits many corner areas where even foremost experts get confused. Obviously then, aspects of the teachability of C++ has challenges. It is fair to say that such feature are:

    But even despite these issues:

    1. There are encouraging and successful tactics to teaching C++.
    2. C++ has never been an elite language.
    3. C++ has many naysayers and much competition in the real world, yet C++ survives and is useful, quite useful in fact.

  4. Some Specifics

    It is thoughts such as those already mentioned why I take issue with many comments expressed in N1426. I would therefore like to address a few issues discussed in N1426 which appear overstated, misleading or biased:

    1. "Export's shadow falls on existing language features."
      This is certainly true. But I find that technical argument clearly uni-directional since there are so many bi-directional interactions that occur in C++. I continue to wonder what the impact of simpler underlying rules would have among each other, upon other complex features, and upon export.
    2. "Potential Objections.... Some vendors have already expended resources implementing and supporting export. This is the strongest argument against removing export. EDG (most notably), and to a lesser extent Comeau, Dinkumware, and Plum Hall, are known to have expended significant effort to date to implement or support export."
      I think that first of all, that if this is indeed the strongest argument against removal, then it is not a potential objection, but quite a real one!

      Second, I think much needs to be said about taking the promises we made by voting in C++98 in a serious way.

      Third, I want to emphasize that there are many non-technical considerations that go into supporting a product. And also that some costs may be non-obvious, indirect or amortized. In other words, the so-called cost of a feature is not always leaping right out, and many features have expensive costs, outright, and ongoing.

    3. "Export can be difficult to use correctly."
      This is very true about many C++ features, especially templates ones. Ditto for features where it is hard to produce good diagnostics, or features which are not easy for programmers to write code with, that have unpredictable results, etc. Hard to use features have always been true and historically been a counter argument against C++.
    4. "Demand reflects misunderstanding."
      This too has traditionally followed many C++ features, and still does. For instance, consider exception handling.
    5. "At least one commercially available compiler ... has already shipped with export disabled (Intel 7.x)."
      Although this is formally correct, more informally, it can be user enabled, although it is currently undocumented and unsupported. But it has shipped.
    6. "There is no known second implementation of export currently planned by any company." and "There is no known announced plan to support export in any other commercially available compiler product."
      However, Herb Sutter posted to the contrary on numerous occasions on usenet that:
      "Microsoft is .... committed to producing a 100% conformant C++ compiler".
      Furthermore, in other posts, more specifically he said:
      "Microsoft is the only vendor I know of, besides EDG and Comeau, who has publicly committed to implementing export."
      and again at a different times, repeating:
      "Microsoft does intend to become fully conformant and to implement all standard C++ features, including export."
      and so on. These are all clear and unambiguous statements, yet there is a conflicting message. This conflict is similar to Stan Lippman's comments in 2001 about conformance and export, which were then said to be premature comments.

      Also, we don't need to focus on commercial compilers.

    7. "Conspicuous lack of demand."
      More conspicuous is probably the widespread suggestion made to people that they have no choice, instead of telling them to complain to their compiler authors. That said, the issue that comes up often enough (on usenet, and in email) is not "How do I do ...separation...?" but "Why am I getting this link error?" Some people naturally expect something like export to work, in fact, they expect it to work without even having to use the export keyword, so they are confused when they get a link error instead.
      Also, if lack of demand is reason enough for removal or non-requirement of a feature, then we should consider many other features for removal. It may make sense to isolate all such features. At the same time, we should try to establish core features of C++, and most especially, their underlying principles.

      Also, if lack of demand is significant, it completely begs for the C++ committee to reject C99 extensions wholeheartedly, yet those features have continued to receive attention by C++ programmers and the C++ committee.

    8. "export almost always makes builds slower, because at least the same amount of compilation work must still be done at prelink time. Export does not even reduce dependencies between template definitions because the dependencies are intrinsic, independent of file organization."
      It's hard to understand how these statement could be made, since it does not have to mean build time is slower. And of course, as with any feature, including templates in general, it depends upon how you use the feature. Anyway, even if the quoted statements were true of existing implementations, the above seems to preclude any possibility to the contrary in additional implementations, or even revised ones. In any event, it has already been shown, say in the case of Dinkumware [3], that these statements do not need to be the case.
    9. "Export is the only major feature in C++98 which is now, and it appears will for the foreseeable future continue to be, widely unsupported in commercial implementations."
      It is certainly not true that except for export that implementations are otherwise conformant. Wide conformance across implementations to Standard C++, even if export is removed, just might be years away still. Even if implementors really are finally closing in on major and minor features, QA et al is surely a real issue to deal with in order to be able to claim conformance.

      Also, we don't need to focus on commercial compilers.

    10. Section 2.6 of N1426 discusses some issues where export has been underspecified and also has effects on existing language features.
      However, again, such effects and underspecified behavior can be said of many features. Furthermore, addressing any such issues should have been considered by the committee in the defect report process, as was done with the hundreds of other considerations we looked at over the past 6 years. Of course, I'm not trying to trivialize any issues, about any feature or their timing, which have already been solved or still need to be solved.
    11. "Standards committees are authorized to entirely remove features without deprecation"
      There was controversy, disagreement, and even statements of not knowing the answer to this on the committee reflector. Even if this is not so, it doesn't mean we need to take this approach. After all, export is not deprecated, nor has the defect report process pointed to such a direction.
    12. "there is no known use of export in production code as of this writing"
      We have customers who've asked for it, though we don't track what features each customer uses.

      And folks like Dinkumware have export available for use in their library. We are not tracking lib implementations either though.

    13. "for the foreseeable future [export] cannot be used in portable code because the vendors do not widely support it"
      It may be true that unique implementations are still forthcoming, but export is already available for:
      • MS-Windows
      • Solaris/SPARC
      • SunOS
      • various LINUXes
      • SCO and other 386 UNIXes
      • NetBSD
      Export implementations on HP, AIX, Macintosh and other platforms are expected shortly. [Comeau -- an alpha and beta MAC OS X version of Comeau C++ has been made available in 2005 that implements export, and a generally available version is expected by the end of 2005.]
    14. "Export is the only major C++ feature that is seriously fracturing the standard's adoption."
      This is not the only serious C++ issue, and saying it is doesn't make it so. Besides, the doom of C++ is not so simple.

    I'm not going to detail every point, nor list every point, so the above is just a sampling of my thoughts.

  5. After all, N1426 Advises Caution Too

    In fact, it's stated in N1426 itself multiple times that we should be cautious. For instance:
    "In summary, it remains to be seen in the coming months and years ..."
    and also
    "It's too early to tell .... Time and experimentation will tell. As vendors slowly begin to adopt and support export in the coming years, and the community gets a chance to finally try it out, we'll know much more about how and when to use it - or not."
    This is just what we've done with every feature. So why don't we do that here?

  6. Conclusion

    Most features in C++ are useful in isolation. Additionally, often the power of C++ is being able to use features in combination. But, that same combinational power often exposes areas under stress. I believe that this is a key issue that document N1426 doesn't expose, and hence becomes misleading. In other words, even if export is removed, underlying problems in C++ remain. That means problems, which are not just with export, still exist, some hurtfully dormant, some blatantly not.

    It's true that implementing export is expensive. But it's significant and important to point out this and many other concerns about export were raised before export was voted upon and before Standard C++ was voted upon. Moreover, as C++03 becomes a reality, there has been no real new information about export to surface. Also, removal of export was not brought up as a defect in DR processing. Nor was it even considered a deprecated feature in our standardization or maintenance processes.

    The committee did not just codify existing practice, it also invented. It's important to note that we voted in many new features, and many of those features have not been perfect. Nor have "old" features been perfect. In fact, many features had, and have, problems and surprises. Just as many "gotcha" style books have been written since the standardization of C++ as before it. Many new features took most implementors a long time to even begin to implement. As well, some companies literally made concrete business decisions to wait before they started implementing Standard C++.

    More generally, C++ is not the easiest language, never has been. Many features are hard to teach, hard to learn, and hard to use. As such, it was no surprise that implementations were delayed. However, as discussed, there are many problem areas in C++ and the problem with C++ is therefore not export.

    In the meantime, Dinkumware [3] has export'ized their library implementation, a library which is a cornerstone of many C++ implementations. And Comeau [4] and Intel [5] have full export implementations via EDG [6], a cornerstone of many C++ implementations. As such, export is already available on a host of different platforms, and will be on even more shortly.

    In fact, vendors such as EDG, Dinkumware and Comeau are now offering full implementations of Standard C++, aka "C++98". Furthermore, the committee has approved the technical details of a revised standard, aka "C++03", which is only awaiting certain bureaucratic approval. Note that EDG, Dinkumware, and Comeau already provide support for C++03. The point to be made here is that complete, good and efficient implementations are not only possible but actually exist. And that it was and is possible to keep atop of things. And so far, has come from the smallest companies. That certainly means that it can also come from the larger companies, and I therefore expect that many other implementors are in hot pursuit.

    The committee made a serious promise by voting in export and for that matter all other features. As such, C++ survives well. It is important to recognize that implementors and developers took the standard seriously. Let's behave responsibly and not underestimate that.

    The committee still has a lot of work to continue with Defect Report processing as well as to begin the "5 year revision period" and should focus its manpower on completing those tasks. I would expect in that process for language issues to be brought to the attention of the core working group, and library problems to be brought to the attention of the library working group. And any recommendation and decisions to go through the normal policies: 2 week rule, waiting through successive meetings, etc. If, during that process, the committee can solidify underlying technical issues, and their interactions, I encourage that as it is really the problem here. Removing problematic features without that information and without an overall analysis is not frugal and a mistake. There are also other possible outcomes, not the least of which is the fine tuning and enhancement of the underlying concern(s) and features they may effect.

  7. References

    [1] SC22/WG21/N1426, aka J16/03-0008, provided as n1426r2.pdf, dated March 3

    [2] Stroustrup, Bjarne. The Design and Evolution of C++ (Addison-Wesley Publishing Company, 1994)

    [3] Dinkumware, Ltd., http://www.dinkumware.com

    [4] Comeau C++, Comeau Computing, http://www.comeaucomputing.com

    [5] Intel C++, Intel Corp, http://www.intel.com

    [6] EDG, Edison Design Group, http://www.edg.com