Home > Uncategorized > The C++ committee has taken off its ball and chain

The C++ committee has taken off its ball and chain

A step change in the approach to updates and additions to the C++ Standard occurred at the recent WG21 meeting, or rather a change that has been kind of going on for a few meetings has been documented and discussed. Two bullet points at the start of “C++ Stability, Velocity, and Deployment Plans [R2]”, grab reader’s attention:

● Is C++ a language of exciting new features?
● Is C++ a language known for great stability over a long period?

followed by the proposal (which was agreed at the meeting): “The Committee should be willing to consider the design / quality of proposals even if they may cause a change in behavior or failure to compile for existing code.”

We have had 30 years of C++/C compatibility (ok, there have been some nibbling around the edges over the last 15 years). A remarkable achievement, thanks to Bjarne Stroustrup over 30+ years and 64 full-week standards’ meetings (also, Tom Plum and Bill Plauger were engaged in shuttle diplomacy between WG14 and WG21).

The C/C++ superset/different issue has a long history.

In the late 1980s SC22 (the top-level ISO committee for programming languages) asked WG14 (the C committee) whether a standard should be created for C++, and if so did WG14 want to create it. WG14 considered the matter at its April 1989 meeting, and replied that in its view a standard for C++ was worth considering, but that the C committee were not the people to do it.

In 1990, SC22 started a study group to look into whether a working group for C++ should be created and in the U.S. X3 (the ANSI committee responsible for Information processing systems) set up X3J16. The showdown meeting of what would become WG21, was held in London, March 1992 (the only ISO C++ meeting I have attended).

The X3J16 people were in London for the ISO meeting, which was heated at times. The two public positions were: 1) work should start on a standard for C++, 2) C++ was not yet mature enough for work to start on a standard.

The, not so public, reason given for wanting to start work on a standard was to stop, or at least slow down, changes to the language. New releases, rumored and/or actual, of Cfront were frequent (in a pre-Internet time sense). Writing large applications in a version of C++ that was replaced with something sightly different six months later had developers in large companies pulling their hair out.

You might have thought that compiler vendors would be happy for the language to be changing on a regular basis; changes provide an incentive for users to pay for compiler upgrades. In practice the changes were so significant that major rework was needed by somebody who knew what they were doing, i.e., expensive people had to be paid; vendors were more used to putting effort into marketing minor updates. It was claimed that implementing a C++ compiler required seven times the effort of implementing a C compiler. I have no idea how true this claim might have been (it might have been one vendor’s approximate experience). In the 1980s everybody and his dog had their own C compiler and most of those who had tried, had run into a brick wall trying to implement a C++ compiler.

The stop/slow down changing C++ vs. let C++ “fulfill its destiny” (a rallying call from the AT&T rep, which the whole room cheered) finally got voted on; the study group became a WG (I cannot tell you the numbers; the meeting minutes are not online and I cannot find a paper copy {we had those until the mid/late-90s}).

The creation of WG21 did not have the intended effect (slowing down changes to the language); Stroustrup joined the committee and C++ evolution continued apace. However, from the developers’ perspective language change did slow down; Cfront changes stopped because its code was collapsing under its own evolutionary weight and usable C++ compilers became available from other vendors (in the early days, Zortech C++ was a major boost to the spread of usage).

The last WG21 meeting had 140 people on the attendance list; they were not all bored consultants looking for a creative outlet (i.e., exciting new features), but I’m sure many would be happy to drop the ball-and-chain (otherwise known as C compatibility).

I think there will be lots of proposals that will break C compatibility in one way or another and some will make it into a published standard. The claim will be that the changes will make life easier for future C++ developers (a claim made by proponents of every language, for which there is zero empirical evidence). The only way of finding out whether a change has long term benefit is to wait a long time and see what happens.

The interesting question is how C++ compiler vendors will react to breaking changes in the language standard. There are not many production compilers out there these days, i.e., not a lot of competition. What incentive does a compiler vendor have to release a version of their compiler that will likely break existing code? Compiler validation, against a standard, is now history.

If WG21 make too many breaking changes, they could find C++ vendors ignoring them and developers asking whether the ISO C++ standards’ committee is past its sell by date.

Categories: Uncategorized Tags: , , ,
  1. Brian M
    April 18, 2018 11:22 | #1

    Yes – well past there sell by date.

    The one and one major advantage of C++ was backwards compatibility.

    Thanks for killing what was once a great universal language.

  2. RajaRaviVarma
    April 18, 2018 12:00 | #2

    I am beginner, so please read the following arguments as polite-doubts.

    First thing, which I don’t understand is, why not just use a older version of compiler if you don’t want to use new language features, or don’t want to break the code?

    This is how Python2 and Python3 interpreters are used. People who don’t want to move to Python3 use Python2 interpreters. Similarly why not use a older compiler!

    The author argues that there is no empirical evidence that new language features helps developers experience. I disagree, Python 3.6 introduced the *async* *await* (coroutine) feature and there are frameworks (like Sanic) primarily depending on this feature and it introduces newer, easy to use patterns.

    JavaScript introduces new features almost every year (I guess) and developers doesn’t wait to use it.

  3. April 18, 2018 12:16 | #3

    @RajaRaviVarma
    Continuing to use the same compiler (which eventually becomes the older compiler) is an option that some people choose to use. But older compilers stop being maintained (e.g., no bug fixes and support for new processors). Life is so much simpler if code can be compiled by the latest compiler.

    The evidence claim was primarily referring to the compatibility argument, but is also true in general. Has anybody compared async or await with alternative ways of supporting the same functionality? Yes, the solutions chosen are useful, but are they better than the alternatives? The only way to find out is to run an experiment.

  4. April 18, 2018 12:56 | #4

    We must not ever lose site of the difference between an international standard and a corporation or association-owned standard. That’s why I based my platform only two ISOs: ISO 8879 SGML and ISO 14882 C++. I can count on 116 C++ professionals to show up at ISO meetings and move the language steadily forwards and prune it where necessary. Please do not ruin that.

  5. April 18, 2018 13:27 | #5

    @Robert Tischer
    ISO committees only have influence if implementers decide to implement what is specified in a standard. Given there are so few implementers out there, they could get together and decide to take C++ (in this case) in a direction of their choosing.

    In the open source world you pay up or shut up.

  6. April 18, 2018 15:29 | #6

    @Derek Jones
    Don’t forget the quality difference between an ISO contributor and a corporate muck. One is guided by prestige and quality, typically academic, and the other from a has-been tech for a boss who ultimately has shareholders to satisfy who definitely are not wise techs. For example, take the deep running discussion between Bjarne Stroustrup and Herb Sutter, both top C++ standard gents. The topic was about how important One Definition Rule was when introducing a new feature compared to the projected ISO delivery time table. ODR wasn’t compromised. I know which type I would trust with issues like that. There must be others out there that would make the same choice.

  7. April 18, 2018 16:28 | #7

    @Robert Tischer
    ISO contributors and corporate mucks are one and the same. The qualifications for attending a WG meeting are being able to afford flight/hotel, being a citizen or working for a company domiciled in a country that is a P member of SC22 (O members only get to observe), and getting yourself on the delegate list (in some countries there is a membership fee and its free in others).

  8. Corporate muck
    April 20, 2018 15:53 | #8

    What “C compatibility” are you talking about, if C is an lvalue-discrding language, while C++ is lvalue-preserving?

    I’d rather be worried about certain companies pushing their agenda in order to turn the language into C#++, introducing ridiculous proposals (such as io2d).

  9. March 21, 2021 22:39 | #9

    You are more optimistic about WG14 than I am. They continue to double down on “optimizations” and type requirements that make the language impossible to use.

  1. No trackbacks yet.