Is the ISO C++ standard’s committee past its sell by date?
The purpose of having a standard is economic. The classic (British) example is screw threads, having a standard set of screw threads means that products from different manufacturers are interchangeable and competition drives down prices; the US puts more emphasis on standards being an enabler of people interchangeability, i.e., train people once and they can use the acquired skills in multiple companies.
In the early days of computing we had umpteen compilers for Cobol, Fortran and then Pascal and then C and then C++. There were a lot of benefit to be had getting the vendors signed up to support a single standard for their language (of course they still added bells and whistles to ‘enhance’ their offerings). Language standard’s meeting were full of vendors, with a few end users (mostly from large corporations and government).
Fast forward to today and the ranks of compiler vendors has thinned significantly. Microfocus dominates Cobol, Fortran is dominated by a few number cruncher oriented companies, Pascal die hards cling on in surprising places, C vendors are till in double figures (down by an order of magnitude from its heyday) and C++ vendors will soon be accurately countable by Trolls (1, 2, 3, many).
What purpose does an ISO language standard serve in a world with only a few compilers? These days the standard is actually set by the huge volume of existing code that has to be handled by any vendor hoping to be adopted by developers.
The ISO C++ committee has become the playground of bored consultants looking for a creative outlet that work is not providing. Is there any red blooded developer who would not love spending a week, two or three times a year, holed up in a hotel with 100+ similarly minded people pouring over newly invented language features?
Does the world need all these new features in C++? Fortunately for the committee there are training companies who like nothing better than being able to offer ‘latest features of C++’ courses to all those developers who have been on previous ‘latest features of C++’ courses. Then there is the media, who just love writing about new stuff, there is even an ‘official’ C++ Standard news outlet.
In the good old days compiler vendors loved updates to the language standard because it gave them an opportunity to sell upgrades to customers; things are a bit different in the open source compiler market. What is the incentive of an open source compiler vendor to support features added by an ISO committee? In the past there has been a community expectation that it will happen, but is the ground swell of opinion enough to warrant spending resources on supporting new languages? Perhaps the GCC and LLVM folk will get together and mutually agree not to waste resources being the first mover.
Would developers at large notice if the C++ committee didn’t do anything for the next 10 years?
The Javascript ECMAscript standard also has a membership that includes many end users. In this case I suspect companies are sending people to make sure that new languages features don’t impact large code bases and existing investment in ways of doing things.
Update: I’m not saying that C++ language and libraries should stop evolving, but questioning the need to have an ISO Standard’s committee in a world of Open Source and a small number of compilers (that is likely to only become fewer).
Obviously Betteridge’s Law of Headlines applies here.
Derek – I normally I find your posts insightful, or at least I respectfully maintain a different opinion but appreciate the coverage.
This time you just seem to be trolling, though!
Let’s see – starting at the end – would developers notice if there was no movement on the standard for 10 years? Hell yes! There was an outcry that a number of much anticipated features didn’t make the cut for C++17 and got bumped to C++20!
We *did* go a period of (more than) 10 years without a standard update and it nearly killed C++. Since the pace has picked up again there has been a renaissance!
As for incentives… it’s interesting that the open source compilers are ahead of the commercial option(s) (which is pretty much just MSVC at this point, yes) in standards conformance. They’re falling over themselves to keep up as quickly as possible. And even MS has been catching up much faster than in the past. There don’t seem to be any problems with the incentives there.
Does the world need the new features? You seem to imply that all the new features are just being added for the sake of it! But C++ was getting embarrassingly out-of-date during it’s wilderness years and most of the features are just catching up to what other modern languages are already doing – or fixing issues with the usability of the previous standard. Writing code in “modern C++” feels fresh and clean – and is more productive than it’s ever been.
You *might* be able to make a case that C++ will never catch up to those modern languages that have had the opportunity of a clean slate – and there’s some truth to that. Perhaps C++ will never be quite as on top of the PL world as it was in it’s heyday. But it remains an important and widely used language that benefits greatly from recent enhancements.
And while added more and more features does increase the overall complexity of the language – many areas have been deprecated – some to the extent of being removed! Sticking to the modern idioms leads to C++ code that is simpler than it’s ever been.
None of this could have happened without the (far from perfect) efforts of the standards committee over the years.
I’m sure the Hawaii meetings do help though 🙂
@Phil Nash
Thanks for posting a comment. If you have a difference of opinion about what I say in future please do comment.
I think you are are talking from the point of view of someone in the C++ Standard’s bubble when you talk about the outcry over C++17 features that got bumped to C++20. The delay between publication of the first and second version of the standard could have warranted an outcry.
I am always skeptical about vendor claims of compiler conformance. Experience with other languages has clearly shown that such claims are generally to be treated as vacuous until backed-up with validation suite results (I am not aware of any for the current round of claims, but have not looked very hard).
How does a language get out of date (embarrassingly or otherwise)? It might not support the latest trendy features, but so what? I can see the need to support new hardware functionality that has become/is becoming common, e.g., transactional memory. What is C++ catching up with, which of these modern languages is anything other than a shiny bauble that will be replaced by the next fashionable language in a few years?
Where is the evidence that developers are suffering because of the lack of the latest trendy feature? Where is the evidence that there is any worthwhile productivity enhancement?
No one doubts the herculean efforts being made by members of the committee. But they seem to be concentrating too much on the fun stuff and not doing enough of the boring stuff like answering defect reports and tidying things up.
Here’s a page with the most recent C++17 developments: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/#mailing2016-07
Personally, I use the more most recent C++ compilers as much as possible. The primary reason is that it’s just more productive. Features like auto, range for, the new libraries, etc, just prevent a lot of annoying boilerplate code and let you get to the point. Bring on the new features, I say!
It was pretty embarrassing for C++ not even to know what a thread is, well after multicore CPUs were entry-level devices. C++11 added threads, synchronisation, atomics, async, etc to the standard library.
The library still has to catch up the huge .NET framework and J2EE library but a lot of it is there now or getting there.
It also has to catch up with development tools (hindered because of the type of grammar, but being helped along by CLang’s AST) and general development experience (should be helped a lot in future C++ with modules and concepts).
Knowing that a chunk of C++, including library calls, will run on platforms ranging from embedded to smartphone to desktop to distributed supercomputer, and with different compilers, is very much a worthwhile goal!
@Magnus
C and C++ worked well together so both standards were as compatible as possible in adding these ‘new’ features.
Does nothing happen in the C++ world unless it appears in the Standard? APIs don’t need a standard, they can grow and evolve on their own without having to wait for the long cycle of committee meetings and ISO voting.
With a handful of compilers and open source, what role is there for the C++ Standard committee?
Plenty happens in C++ if there’s not a standard to police it, that’s the problem! Two examples, to compare and contrast:
1. Boost – the writers work hard to make boost work with all C++ compilers, even old versions. A lot of boost has been moved into the C++11/14/… standard library. But boost has a lot of negatives (that I won’t go into).
2. MSVC – MS’s attempt to .NETify C++ (C++.NET) was almost universally rejected by the rest of the C++ world. They have tried again with a softer, gentler approach with C++/CX, but most C++ coders still don’t like it. MS (through Herb Sutter, the chairman of the C++ committee; I haven’t met him but I don’t think you’d find a nicer guy) says the CX features are necessary to interact with the ‘modern’ API, and it’s easy to bundle the CX stuff away from your pristine C++.
I don’t think anyone wants to return to the days before the committee became active again.
APIs are what they are, plenty are available to C++. .NET, Java, Python (sort of) have one. Think of a tutorial these days in learning a language. Quite early you’re going to want your programme to do something “on the internet”. There’s no standard way in C++ to do that right now! (C++17 should have an API based on boost asio.) You can’t put -everything- in a standard library, but C++ has had almost nothing, and the committee saw that as one of its biggest problems.
C++11 took a long time to finish (in development it was called C++0x, where ‘x’ was supposed to be a single digit), and now the committee has committed to a higher ‘cadence’, as they put it. It also took a long time for compilers to catch up to 11, but I think the main ones (MSVC, CLang, GCC, does Intel still do their own compiler?) will have most if not all of 17 before it’s ratified.
I think it would be absolutely terrible if the C++ committee went away. Even if all the compilers eventually die and only CLang is left standing (I hope that doesn’t happen), we still need the committee to represent all the users and codebases, all of whom have many different current and future needs.
To wrap up with one example to think about where a disinterested committee is better than an implementation to define standard C++: undefined behaviour.
@Magnus
The C++ Standard’s committee has no policing role, in fact no organization polices any ISO Standard. They publish a document and implementers can do what they like with it.
Vendors are free to produce whatever libraries they like. It is their customer who decide whether a particular library is a success. Again, nothing to do the the C++ Standard.
Why do compilers need to implement anything that the C++ committee decides should be in their official document? They could form a committee of three and do their own thing.
I’ll just say that the C++ community (developers, tool builders, language lawyers) trust the committee, and give it credibility. This means vendors are pressured to comply, and not lag behind, or veer away from, the standard specification. I’m sure a lot of boondoggling goes on in relation to the ISO, but the C++ world doesn’t view the C++ committee as bored consultants.
So I guess it’s C++ users themselves who do the enforcing, which is why they like a strong, credible standard. This is what I mean by the standard policing vendors. Sure, the ISO doesn’t do this itself, and it’s a fairly, but not very, interesting question to me about how exactly one goes about forbidding someone from calling a product “C++”.
Enhancements to the standard come from lots of different directions (improvements from compiler vendors, transactional and heterogeneous memory, GPGPUs CUDA/OpenCL, tooling and general developer experience improvements which may require language modifications like modules and reflection). Vendors create their products, the committee responds to users’ wishes and pick the best bits, and the standard then works for everyone and not one particular vendor. Rainbows and lollypops for everyone!