31

Does the C++ committee test their new design specifications with some sort of prototype compiler before releasing a new standard? Or do they release a standard which is, in effect, only theoretical until the big compilers implement it?

Matthew James Briggs
  • 1,757
  • 3
  • 15
  • 23

1 Answers1

27

The C++ Standard Committee has bylaws and rules, but most of these are centered around the structure of the organization, how to submit proposals, voting, publishing the standard, etc. and not so much on the technical details of the standard itself or how it may be tested.

There is no formal requirement for "testing" a feature or its design as far as I know. C++ is also somewhat unique in that there is no reference or "primary" implementation (e.g. Microsoft CLR, Oracle JDK, Zend PHP). However, the committee members consist of many organizations with deep knowledge of the language and compiler implementation. For example, if you follow that previous link, you will see representatives from Microsoft and Intel who both have well-respected C++ compilers. Red Hat and a few other companies who contribute to GCC are also involved.

When proposing a new feature, committee members already have a pretty good idea as to whether it is feasible, if it may conflict with other features, or cause the grammar to be ambiguous in a way that complicates parsing unnecessarily. (here is a good question about C++'s grammar)

The short answer is "no, the committee does not require testing their designs using prototyping." However, there is not much need because the committee members are experts in C++ who understand all the fine details at a level that the vast majority of programmers do not. Remember, these people are language architects who are experts on language theory and compiler design.

Given the involvement of compiler vendors in the process, it is feasible that one or more of them may prototype a new feature, but again, there is no formal requirement for this nor is it something I have read about in publicly-available documents from the C++ Committee.

They also tend to be very conservative, incrementally adding new features that have a demand in the real world without specifying large amounts of new features that may prove to be risky. In fact in recent years they have added new features that existed as proprietary extensions or open-source libraries that already work in the real world. For example, C++11 and C++14 incorporate parts of Boost, which has already been tested in the real world in multiple compilers and execution environments. There is no need to test something that is already tested.

Community
  • 1
  • 5
    [ConceptGCC](http://generic-programming.org/software/ConceptGCC/) and [ConceptClang](http://generic-programming.org/software/ConceptClang/) are two examples of compilers (or rather forks of compilers) that were explicitly created to prototype and gain real experience with a complex language feature. Concepts are also an example of how thorough language features are designed in C++: Concepts have been around since 1998, first as an informal idea to talk about C++ Templates, then in 2006 as a proposed language feature by Bjarne himself, and also implemented in ConceptGCC since then. They *may* … – Jörg W Mittag Mar 20 '16 at 23:47
  • 3
    … end up in C++17, which means that they will have matured for about 10 years as an implementation and 20 years as an idea. – Jörg W Mittag Mar 20 '16 at 23:47
  • 2
    This is mostly false, I think. New features usually [require](http://herbsutter.com/2016/03/11/trip-report-winter-iso-c-standards-meeting/) an [implementation](http://honermann.net/blog/?p=3) first. The one time this didn't happen, we got export. – isanae Mar 21 '16 at 00:25
  • 5
    The last paragraph is (to put it lightly) nonsense. The C committee is very conservative, but C++ adds all sorts of new stuff all the time with little consideration for what a mess it makes the language or whether it actually solves the problems people want to solve. – R.. GitHub STOP HELPING ICE Mar 21 '16 at 01:05
  • 1
    @R.. I disagree. C++11 was an anomaly, but it included a lot of stuff that already existed (see my Boost comment, for example). For much of C++'s life it has evolved _very_ slowly, which is one major complaint that many developers have about the language. –  Mar 21 '16 at 04:44
  • The `export` feature is how the cfront implementation actually worked. The macro-like header implementations were introduced by other vendors. – JDługosz Mar 21 '16 at 05:56
  • 1
    @JDługosz: No, it **very** much wasn't. The real `export` allowed far more complex instantiations, where you'd recursively instantiate across translation units. That's not just theory, I actually tested this with the EDG compiler in 2002 or so. – MSalters Mar 21 '16 at 07:44
  • The original cfront implementation wasn't very solid in what it could accomplish. A separate pass was performed before linking to generate the needed instantiations. The first C++ standard, based on the ARM, tried to specify more exactly the semantics and feature set. That was around 1990. – JDługosz Mar 21 '16 at 08:26
  • 1
    I can't find my copy of the ARM (it's not where it belongs) but it's referenced in *the Design and Evolution of C++* section 15.2: version of Cfront in 1989. Lippmann/McClusky expanded it, a Texas Instruments public-domain version too; caution ruled and the ARM was then deliberately minimal; *that* was accepted by the ISO comittee in Juky 1990. – JDługosz Mar 21 '16 at 08:41
  • My memory is that "both ways" were standardized; the macro-like header way (with fancy name lookup rules that would make it less macro-like if implementations actually did that) was now the default, and `export` was used to make it work "like cfront (and Stroustrup's descriptions) did it". – JDługosz Mar 21 '16 at 08:44
  • As of the writing of *D&E* (1994), he still noted his preference "templates don't belong in headers" (15.10.4). Also, reminded me that cfront relied on a naming convention for filenames. – JDługosz Mar 21 '16 at 09:04