- いくつかのエキサイティングな新機能を備えたC ++言語ですか？
- C ++は、長期間にわたる優れた安定性で知られる言語として知られていますか？
その後、次の提案（会議で合意された）が続きます：「委員会は、これらの提案が言語の振る舞いの変更や既存のコードのコンパイルエラーを引き起こす可能性がある場合でも、提案のデザイン/品質を考慮する準備を整える必要があります。」
私たちの背後にある-30年間のC ++ / C互換性（まあ、過去15年間に、私たちが端に寄りかかって「いちゃいちゃした」とき、ささいなことの小さなケースがありました）。 これは驚くべき成果であり、Bjarn Straustrupと、標準化委員会が30年以上開催した64回の会議に感謝します（Tom PlumeとBill Plagerは、WG14とWG21の間のこの困難な問題に代わりました）。
C / C ++のスーパーセットには長い歴史があります。
1980年代後半、 SC22 （プログラミング言語に関する最高レベルのISO委員会）はWG14（C委員会）にC ++の標準を作成すべきかどうかの質問をしました。もしそうなら、WG14は作成を開始したいと思います。 WG14は1989年4月の会議でこの問題に対処し、C ++標準の作成は注目に値するが、C委員会はそれを行うべき人ではないと判断した。
1990年、SC22はC ++ワーキンググループを作成することが理にかなっているかどうかを調べるためのトレーニンググループを設立し、US X3（情報処理システムを担当するANSI委員会）はX3J16を設立しました 。 将来WG21になることになった人々の会議反対は、1992年3月にロンドンで開催されました（そして、これは私が出席した唯一のISO C ++会議でした）。
X3J16のメンバーはISOを満たすためにロンドンに来て、時々議論が熱くなりました。 2つの主要な世論は、次のようなアイデアでした。
- C ++標準で作業を開始する必要があります。
- C ++はまだ標準で動作するほど成熟していません。
多くの人々が標準の作業を開始したいと考えていた理由は、公に言及することは慣習的ではありませんでしたが、言語の変化の出現を止めたい、または少なくとも遅くしたいという願望でした。 Cfrontの新しいリリースは、それらについてのうわさとともに、非常に頻繁に行われました（インターネットより前の時代の標準でできる限り）。 大企業の開発者は、大規模なアプリケーションで作業を開始してから6か月後に、C ++バージョンがわずかに変更された新しいバージョンに置き換えられたときに髪を引き裂きました。
コンパイラのメーカーは、言語が定期的に変更されたことを喜んでいるように思われるかもしれません-変更は、コンパイラの更新の購入に対して開発者にインセンティブを与えるためです。 実際には、変更は非常に重要であったため、この作業には自分が何をしているかを本当に知っている人が必要でした-つまり 強力なプログラマーに多額の給与を支払う必要があります。 コンパイラのメーカーは、小さなアップデートのマーケティングにお金を使うことにはるかに慣れていました。 C ++コンパイラの実装には、Cコンパイラの実装よりも7倍のコストが必要であると主張されました。このステートメントが実際にどの程度真実であったかはわかりません（おそらく、これはおおよその経験に基づいたメーカーの1つの推定にすぎません）。 1980年代には、各人と彼の犬がそれぞれ独自のCコンパイラを持っていましたが、C ++コンパイラを実装しようとした人のほとんどはレンガの壁にぶつかりました。
最後に、投票が続きました：C ++の変更の採用速度を停止/減速する価値はありますか？-C ++が「その目的を果たす」ことを許可しないこと（AT＆Tの代表者が聴衆に訴えたため、部屋全体が賞賛した） その結果によると、研究グループはWGに変わりました（また、正確な数字をあなたと共有することはできません-このイベントに関するオンラインデータはなく、紙のコピーは見つかりません-90年代半ば/後半まで使用しました）。
Straustrupが委員会に参加し、C ++の進化が速いペースで続いたため、WG21の作成には期待されていた効果がありませんでした（言語の変更が遅くなりました）。 ただし、単純な開発者の観点からは、言語の変更はよりゆっくりと発生し始めました。 Cfrontは、以前の進化の負担でコードが崩壊し始めたため、更新がすぐに停止しました-そして、実際に使用できる適切なC ++コンパイラが登場し始めました（初期の頃、Zortech C ++コンパイラは、言語の人気に対する強力な刺激になりました）。
最新のWG21会議には、訪問者リストに140人が含まれていました。 彼らのすべてが創造的なアウトレットを探している退屈したコンサルタントではなかった（私は「新しい刺激的な機会」について話している）-しかし、多くの人が彼らの手と足を縛るシャックルを取り除くことで幸せになると確信しています（互換性として知られています） C）で。
Cとの互換性を何らかの形で壊す多くの提案が私たちを待っているようで、それらのいくつかは公開された標準に落ちます。 これは、これらの変更が将来のC ++開発者の生活を楽にするという議論によって裏付けられます（各言語の支持者は同様の声明を出しますが、これに関する経験的証拠はありません）。 変更が長期的な利益をもたらすかどうかを確認する唯一の方法は、長く待って、最終的に何が起こるかを確認することです。
ここで興味深い質問は、コンパイラの製造元が互換性を「破る」言語標準の大きな変更にどのように対応するかです。 現在、 積極的に使用されているコンパイラは多くありません 。 競争はそれほど大きくありません。 コンパイラーメーカーが新しいバージョンをリリースするインセンティブは何でしょうか。これにより、ほぼ確実にこの前に書かれたコードが「壊れる」でしょうか。 実際、標準に関するコピレーターの検証は過去のものです 。
WG21が深刻な「重大な」変更をあまりにも多く行う場合、C ++コンパイラの製造元がそれらを無視することを決定する可能性が完全にあり、開発者はC ++の標準化のためのISO委員会の期限が切れたかどうかを考えるでしょう。
Redditについての議論 。