The C ++ Standardization Committee rips the shackles off
A radical change in the approach to updates and additions in the C ++ Standard happened at the recent WG21 meeting — or rather, it was a change that “hung in the air” during the last few meetings, and now finally was discussed by the committee and documented . Attention readers should draw two key points at the very beginning of the document "With ++: plans for stability, speed and implementation of the language" ( C ++ Stability, Velocity, and Deployment Plans [R2] ) ":
They are followed by the following sentence (which was agreed at the meeting): “The committee should be ready to consider the design / quality of the sentences, even if these proposals may cause a change in language behavior or compilation errors of an existing code”.
Behind us is 30 years of C ++ / C compatibility (well, in the last 15 years there have been trivial small cases where we have rested against the edges and "flirted" with it). This is a remarkable achievement, for which we have been thanking Bjarn Stroustrup for 64 years and 64 meetings held by the Standardization Committee (Tom Plum and Bill Plager occupied their place in this difficult matter between WG14 and WG21).
The C / C ++ superset has a long history.
')
In the late 1980s, SC22 (the highest-level ISO committee on programming languages) asked the WG14 (the C committee) whether a standard for C ++ should be created - and, if so, whether WG14 wanted to create it. WG14 considered this issue at a meeting in April 1989 and decided that they considered the creation of a C ++ standard is worth attention, but the C committee is not the kind of people who should be doing this.
In 1990, SC22 established a training group that needed to find out whether it made sense to create a C ++ working group, and US X3 (the ANSI committee responsible for information processing systems) established X3J16 . The meeting-confrontation 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).
The X3J16 participants came to London for an ISO meeting, and from time to time the debates got really hot. The two main public opinions were the ideas that:
The reason why many people wanted to start work on the standard, and which it 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 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 on their heads when, six months after starting work on a large application, the C ++ version was replaced with a new, slightly modified one.
It may seem that compiler manufacturers should be happy that the language has changed regularly - because changes have given 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 really knew what they were doing — that is, it was necessary to pay a large salary to strong programmers; compiler manufacturers were much 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 far this statement was true in practice (perhaps this is just an estimate of one of the manufacturers based on his exemplary experience). In the 1980s, every person and his dog had his own C compiler, but most of those who tried to implement the C ++ compiler rested against a brick wall.
Finally, a vote followed: is it worth stopping / slowing the speed at which changes in C ++ are accepted - against allowing C ++ to "fulfill its purpose" (as AT & T's 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 exact figures with you - there is no online data about this event, and I can’t find a paper copy - we used these until the middle / end of the 90s).
The creation of WG21 did not have the effect expected of it (slowing down changes to the language), since Stroustrup 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 as quickly as its code began to collapse under the weight of previous evolution - and adequate C ++ compilers began to appear, which could be used in practice (in those early years, the Zortech C ++ compiler became a powerful stimulus for the popularity of the language).
The last WG21 meeting included 140 people on the visitors list; Not all of them were bored out of life consultants who are looking for a creative outlet (I’m talking about “great new opportunities”) - but I’m sure that many would be happy to get rid of the shackles that bind them hand and foot (better known 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 (a similar statement is made by supporters of each language, despite the fact that there is no empirical evidence of this). The only way to find out if the change will bring long-term benefits is to wait and see what happens in the end.
An interesting question here is how compiler manufacturers will react to major changes in the standard of the language, "breaking" its compatibility. Currently there are not so many actively used compilers , i.e. the competition is not so great. What will be the incentive for the compiler manufacturer to release its new version, which will almost certainly break the previously written code? After all, the validation of copilators relative to the standard is a thing of the past .
If WG21 makes too many serious “breaking” changes, then it is quite possible that the producers of compilers for C ++ will decide to ignore them - and the developers will think about whether the C ++ ISO standard committee has not expired .
Reddit talk .
- Is C ++ a language with great 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 sentence (which was agreed at the meeting): “The committee should be ready to consider the design / quality of the sentences, even if these proposals may cause a change in language behavior or compilation errors of an existing code”.
Behind us is 30 years of C ++ / C compatibility (well, in the last 15 years there have been trivial small cases where we have rested against the edges and "flirted" with it). This is a remarkable achievement, for which we have been thanking Bjarn Stroustrup for 64 years and 64 meetings held by the Standardization Committee (Tom Plum and Bill Plager occupied their place in this difficult matter between WG14 and WG21).
The C / C ++ superset has a long history.
')
In the late 1980s, SC22 (the highest-level ISO committee on programming languages) asked the WG14 (the C committee) whether a standard for C ++ should be created - and, if so, whether WG14 wanted to create it. WG14 considered this issue at a meeting in April 1989 and decided that they considered the creation of a C ++ standard is worth attention, but the C committee is not the kind of people who should be doing this.
In 1990, SC22 established a training group that needed to find out whether it made sense to create a C ++ working group, and US X3 (the ANSI committee responsible for information processing systems) established X3J16 . The meeting-confrontation 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).
The X3J16 participants came to London for an ISO meeting, and from time to time the debates got really hot. The two main public opinions were the ideas that:
- you need to start working on the C ++ standard;
- C ++ is not mature enough to work on a standard.
The reason why many people wanted to start work on the standard, and which it 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 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 on their heads when, six months after starting work on a large application, the C ++ version was replaced with a new, slightly modified one.
It may seem that compiler manufacturers should be happy that the language has changed regularly - because changes have given 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 really knew what they were doing — that is, it was necessary to pay a large salary to strong programmers; compiler manufacturers were much 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 far this statement was true in practice (perhaps this is just an estimate of one of the manufacturers based on his exemplary experience). In the 1980s, every person and his dog had his own C compiler, but most of those who tried to implement the C ++ compiler rested against a brick wall.
Finally, a vote followed: is it worth stopping / slowing the speed at which changes in C ++ are accepted - against allowing C ++ to "fulfill its purpose" (as AT & T's 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 exact figures with you - there is no online data about this event, and I can’t find a paper copy - we used these until the middle / end of the 90s).
The creation of WG21 did not have the effect expected of it (slowing down changes to the language), since Stroustrup 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 as quickly as its code began to collapse under the weight of previous evolution - and adequate C ++ compilers began to appear, which could be used in practice (in those early years, the Zortech C ++ compiler became a powerful stimulus for the popularity of the language).
The last WG21 meeting included 140 people on the visitors list; Not all of them were bored out of life consultants who are looking for a creative outlet (I’m talking about “great new opportunities”) - but I’m sure that many would be happy to get rid of the shackles that bind them hand and foot (better known 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 (a similar statement is made by supporters of each language, despite the fact that there is no empirical evidence of this). The only way to find out if the change will bring long-term benefits is to wait and see what happens in the end.
An interesting question here is how compiler manufacturers will react to major changes in the standard of the language, "breaking" its compatibility. Currently there are not so many actively used compilers , i.e. the competition is not so great. What will be the incentive for the compiler manufacturer to release its new version, which will almost certainly break the previously written code? After all, the validation of copilators relative to the standard is a thing of the past .
If WG21 makes too many serious “breaking” changes, then it is quite possible that the producers of compilers for C ++ will decide to ignore them - and the developers will think about whether the C ++ ISO standard committee has not expired .
Reddit talk .
Source: https://habr.com/ru/post/353940/
All Articles