April 20, 2018 at 14:21C ++ Standardization Committee breaks shackles
- Transfer
A radical change in approach to updates and additions in the C ++ Standard occurred at a recent meeting of WG21 , - or rather, it was a change that "hung in the air" for the past several meetings, and now has finally been discussed by the committee and documented . The reader’s attention should be drawn to two key points at the very beginning of the document “C ++: plans for stability, speed and implementation of the language” ( C ++ Stability, Velocity, and Deployment Plans [R2] ):
They are followed by the following proposal (which was agreed at the meeting): “The committee should be prepared to consider the design / quality of the proposals even if these proposals could cause a change in the behavior of the language or compilation errors of existing code.”
Behind us is 30 years of C ++ / C compatibility (well, well, in the last 15 years there have been small cases of little things when we rested on the edges and “flirted” with it). This is a remarkable achievement, for which we have thanked Bjarn Straustrup and 64 meetings held by the standardization committee for more than 30 years (Tom Plume and Bill Plager took their place in this difficult matter between WG14 and WG21).
A superset of C / C ++ has a long history.
Late 1980s SC22(the highest-level ISO committee on programming languages) asked WG14 (the C committee) the question of whether a standard for C ++ should be created - and if so, would WG14 want to work on creating it. The WG14 addressed this issue at a meeting in April 1989 and decided that in their opinion the creation of the C ++ standard is worth the attention, but the C committee is not the kind of people who should do it.
In 1990, SC22 established a training group to find out if it makes sense to create a C ++ working group, and US X3 (the ANSI committee responsible for information processing systems) established X3J16. The meeting-opposition of those who were to become WG21 in the future was held in London in March 1992 (and this was the only ISO C ++ meeting I attended).
X3J16 members came to London to meet the ISO, and from time to time the debate got really hot. The two main public opinions were ideas that:
The reason why many wanted to start working on the standard, and which was not customary to mention publicly, was the desire to stop, or at least slow down, the appearance of changes in the language. New releases of Cfront , along with rumors about them, were quite frequent (as much as it could be done by the standards of the era before the Internet). Developers from large companies tore their hair off when six months later after starting work on a large application, the C ++ version was replaced with a new, slightly modified one.
It might seem that compiler manufacturers should have been glad that the language changed regularly - because the changes gave an incentive to developers to pay for the purchase of compiler updates. In practice, the changes were so significant that this work required those who reallyknew what they were doing - i.e. required to pay a large salary to strong programmers; compiler manufacturers were far more accustomed to spend money on marketing small updates. It was argued that the implementation of the C ++ compiler required seven times more costs than the implementation of the compiler for C. I have no idea how true this statement was in practice (perhaps this is only an estimate from one of the manufacturers based on his approximate experience). In the 1980s, each person and his dog had their own C compiler, but most of those who tried to implement the C ++ compiler ran into a brick wall.
Finally, a vote followed: is it worth stopping / slowing down the speed of adoption of changes in C ++ - against allowing C ++ to "fulfill its purpose" (as the AT&T representative put it in his appeal to the audience, as a result of which the whole room applauded). According to its results, the research group turned into WG (alas, I can’t share the exact numbers with you - there is no online data about this event, and I can’t find a paper copy - we used it until the mid / late 90s).
The creation of WG21 did not have the effect that was expected of it (slowing down changes to the language), since Straustrup joined the committee and the evolution of C ++ continued at a fast pace. However, from the point of view of simple developers, changes in the language began to occur more slowly; Cfront stopped updating so quickly, because its code began to collapse under the burden of the previous evolution - and adequate C ++ compilers began to appear that could be used in practice (in those early years, the Zortech C ++ compiler was a powerful stimulus for the growth of the language's popularity).
The most recent WG21 meeting included 140 people on the visitor list; not all of them were bored consultants who are looking for a creative outlet (I'm talking about “exciting new opportunities”) - but I’m sure that many would be happy to get rid of the shackles that bind their hands and feet (better known as compatibility with C).
It seems to me that a lot of proposals await us that will break compatibility with C in one way or another, and some of them will fall into the published standard. This will be supported by the argument that these changes will make life easier for future C ++ developers (proponents of each language make such a statement, although there is no empirical evidence for this). The only way to find out if a change will bring long-term benefits is to wait long and see what happens in the end.
An interesting question here is how compiler manufacturers will respond to major changes to the language standard that “break” its compatibility. Currently, there are not many actively used compilers, i.e. competition is not so great. What will be an incentive for the compiler manufacturer to release its new version, which will almost certainly “break” the code written before this? Indeed, the validation of copilators with respect to the standard is a thing of the past .
If WG21 makes too many serious “breaking” changes, then it is entirely possible that C ++ compiler manufacturers will decide to ignore them - and the developers will think about whether the ISO committee for standardization of C ++ has expired .
Discussion on Reddit .
- Is a C ++ language that has some exciting new features?
- Is C ++ known as a language known for its excellent stability over a long period of time?
They are followed by the following proposal (which was agreed at the meeting): “The committee should be prepared to consider the design / quality of the proposals even if these proposals could cause a change in the behavior of the language or compilation errors of existing code.”
Behind us is 30 years of C ++ / C compatibility (well, well, in the last 15 years there have been small cases of little things when we rested on the edges and “flirted” with it). This is a remarkable achievement, for which we have thanked Bjarn Straustrup and 64 meetings held by the standardization committee for more than 30 years (Tom Plume and Bill Plager took their place in this difficult matter between WG14 and WG21).
A superset of C / C ++ has a long history.
Late 1980s SC22(the highest-level ISO committee on programming languages) asked WG14 (the C committee) the question of whether a standard for C ++ should be created - and if so, would WG14 want to work on creating it. The WG14 addressed this issue at a meeting in April 1989 and decided that in their opinion the creation of the C ++ standard is worth the attention, but the C committee is not the kind of people who should do it.
In 1990, SC22 established a training group to find out if it makes sense to create a C ++ working group, and US X3 (the ANSI committee responsible for information processing systems) established X3J16. The meeting-opposition of those who were to become WG21 in the future was held in London in March 1992 (and this was the only ISO C ++ meeting I attended).
X3J16 members came to London to meet the ISO, and from time to time the debate got really hot. The two main public opinions were ideas that:
- need to start work on the C ++ standard;
- C ++ is not yet mature enough to work on the standard.
The reason why many wanted to start working on the standard, and which was not customary to mention publicly, was the desire to stop, or at least slow down, the appearance of changes in the language. New releases of Cfront , along with rumors about them, were quite frequent (as much as it could be done by the standards of the era before the Internet). Developers from large companies tore their hair off when six months later after starting work on a large application, the C ++ version was replaced with a new, slightly modified one.
It might seem that compiler manufacturers should have been glad that the language changed regularly - because the changes gave an incentive to developers to pay for the purchase of compiler updates. In practice, the changes were so significant that this work required those who reallyknew what they were doing - i.e. required to pay a large salary to strong programmers; compiler manufacturers were far more accustomed to spend money on marketing small updates. It was argued that the implementation of the C ++ compiler required seven times more costs than the implementation of the compiler for C. I have no idea how true this statement was in practice (perhaps this is only an estimate from one of the manufacturers based on his approximate experience). In the 1980s, each person and his dog had their own C compiler, but most of those who tried to implement the C ++ compiler ran into a brick wall.
Finally, a vote followed: is it worth stopping / slowing down the speed of adoption of changes in C ++ - against allowing C ++ to "fulfill its purpose" (as the AT&T representative put it in his appeal to the audience, as a result of which the whole room applauded). According to its results, the research group turned into WG (alas, I can’t share the exact numbers with you - there is no online data about this event, and I can’t find a paper copy - we used it until the mid / late 90s).
The creation of WG21 did not have the effect that was expected of it (slowing down changes to the language), since Straustrup joined the committee and the evolution of C ++ continued at a fast pace. However, from the point of view of simple developers, changes in the language began to occur more slowly; Cfront stopped updating so quickly, because its code began to collapse under the burden of the previous evolution - and adequate C ++ compilers began to appear that could be used in practice (in those early years, the Zortech C ++ compiler was a powerful stimulus for the growth of the language's popularity).
The most recent WG21 meeting included 140 people on the visitor list; not all of them were bored consultants who are looking for a creative outlet (I'm talking about “exciting new opportunities”) - but I’m sure that many would be happy to get rid of the shackles that bind their hands and feet (better known as compatibility with C).
It seems to me that a lot of proposals await us that will break compatibility with C in one way or another, and some of them will fall into the published standard. This will be supported by the argument that these changes will make life easier for future C ++ developers (proponents of each language make such a statement, although there is no empirical evidence for this). The only way to find out if a change will bring long-term benefits is to wait long and see what happens in the end.
An interesting question here is how compiler manufacturers will respond to major changes to the language standard that “break” its compatibility. Currently, there are not many actively used compilers, i.e. competition is not so great. What will be an incentive for the compiler manufacturer to release its new version, which will almost certainly “break” the code written before this? Indeed, the validation of copilators with respect to the standard is a thing of the past .
If WG21 makes too many serious “breaking” changes, then it is entirely possible that C ++ compiler manufacturers will decide to ignore them - and the developers will think about whether the ISO committee for standardization of C ++ has expired .
Discussion on Reddit .