現代のC ++：それは何であり、どのように生まれたのですか？
過去10年間、C ++ 11標準の出現により、その前に-TR1仕様とその前にあるBoostライブラリが-開発者のC ++コミュニティで、新しいプログラミングスタイル、いわゆるモダンC ++への大規模な移行がありました。 この移行には、 autoキーワード、クロージャ（ラムダ式）、変数パターンなどのテクニックの導入が含まれていました。 C ++は実験に適した基盤であることが判明し、いくつかのライブラリが新しいスタイルで記述されました。 SFINAE、タグディスパッチ、CRTP、タイプジェネレータ、セーフブールなどの新しいイディオムを理解できた人、または少なくともそれらの再現方法を学んだ人には、教祖の称号が授与されました。
1970年代初頭に登場しました。 Martin-Löfの型の直観主義理論は、純粋な数学とコンピューターサイエンスの交差の結果であり、 AgdaやEpigramなどの新しい型言語の分野で活発な研究が始まりました。 そのため、 関数型プログラミングパラダイムの基礎が築かれました。 これらのすべての理論は現在、大学で教えられており、「ブレークスルー」として宣言されており、その開発と促進に莫大な金額が投資されています。 アメリカのビジネスの間でこの「ブレークスルー」を促進する生計を立てているスピーカーのコミュニティさえありました。 したがって、C ++標準化委員会の現在の決定が新しいメンバー、つまりこの環境の影響下で意見が形成された昨日の学生によって積極的に影響を受けることは驚くことではありません。
パフォーマンスから機能への方向転換
時間が経つにつれて、C ++は「高速」言語から「機能的」言語に進化し、パフォーマンスは忘れられていました。 iostreamライブラリや文字列など、一部のC ++コンポーネントは、その性質上、すぐに動作できないことは誰にとっても秘密ではありません。 さらに、ネットワークを介したデータ転送の制御などの基本的な機能や、最も単純な改行手順などの非常に基本的な機能はありません。 委員会のメンバーに過去20年間これらの欠点が解消されなかった理由を尋ねると、答えは常に同じになります。誰も対応するレポートや提案の準備に煩わされたくなかったからです。
委員会は、低遅延ソフトウェア業界の専門家の間で言語のさらなる改善を議論するためのプラットフォームとして、ISO 21ワーキンググループ（WG21）のGame Development and High Frequency Trading（HFT）部門の一部門であるSG14研究グループを使用する予定です。 しかし、ディスカッショングループとMichael Wang Standard （その内容は名前と同じくらいおもしろい）で既に行われているディスカッションから判断すると、C ++がこの分野で「C ++ with classes」とうまく競争するために必要な抜本的な改革を実行したい人はいません「。
そして、なぜこれが問題なのでしょうか？
私は、戦略的投資とアプリケーションパフォーマンスの最適化と向上の両方の問題について、コンサルタントとして多数の開発会社のC ++コードの専門家による分析を行っています。私自身の経験から、現代のC ++で書かれたプログラムのパフォーマンスには多くの要望があると確信しています。 その理由は、新しいスタイルでは低レイテンシの高性能システムを作成できないからではなく、開発プロセス中にプログラマの作業を麻痺させたり、コンパイラにとって困難な非常に困難な最適化グラフを生成したりする多くの障害があるからです。 チャンドラー・カルトの一連のビデオ講義があることは非常にうれしいです。おかげで、C ++言語と現実の間の失われた接続を復元することができます（同時に、少し健全になります）。
性能低下
既に述べたように、最初の障害は、中間コード表現構造とコンパイラーパスのより複雑な構造によるパフォーマンスの潜在的な損失です。 この観点から見ると、Fortranの方がはるかに優れています。Fortranはより単純で、コンパイラは同様のC / C ++コードに比べてはるかに効率的に最適化できるためです。 長年にわたるHFTとゲーム開発の分野での私自身の経験と、権威ある査読済み出版物のデータ、そして実際にコンパイラーの最適化に少し精通している人の観察は、通常のテンプレートと可変テンプレートが出力を得ることができるという広範な信念があることを示していますコンパイル段階でのC ++コードの自動「解散」によるはるかに高速なアセンブリコードは、実際には確認されていません 。 これは妄想に過ぎませんが、非常に安定しています。 実際、逆のことが当てはまります。テンプレートよりも生成されたアセンブラコードを操作する場合、小さなコードフラグメントのコンパイル、デバッグ、最適化がはるかに優れています。
コンパイル時間
次の問題は、コンパイル時間に関連しています。 通常のテンプレートと可変テンプレートは、従来のスタイルと比較してプロセスに含まれる非常に多くのファイルの再アセンブリにより、コンパイル時間を数十倍に増やすことができることで「有名」です。 C ++の単純な従来のクラスは、それに直接含まれるヘッダーファイルが変更された場合にのみ再コンパイルされますが、現代のC ++では、1つの小さな変更によりプロジェクトの完全な再アセンブリが必要になることが多く、多くの場合、最大10分かかります。 クラシックC ++の場合、今度は同じ小さな編集で数秒です。
プログラマが生成されたアセンブラコードのテストを開始し、プログラムに必要な変更を加え終えるまでの時間は、生成されたコードの品質に依存します。 アプリケーションを迅速に組み立ててテストできる場合、すべての問題領域がより高い確率で修正されます。 コンパイルに10分かかる場合、この確率は大幅に減少します。
護衛
3番目の最後のハードルは、コードの複雑さに関連しています。 Edsger Dijkstraがかつて言ったように、
シンプルさが信頼性の鍵です。
コードを理解するためにプログラミングの第一人者を雇わなければならない場合、コードに何か問題があるか、選択した言語が解決するタスクに適していないかのいずれかです。
おそらくダイクストラの最も有名な記事 「 gotoの危険性について」を注意深く読むと、その最も重要な規定がテンプレート（通常および可変）に適用されることは簡単にわかります。問題はメカニズム自体が悪いことではありませんが、それに固有の固有の構造は必然的に複雑なコードを生成し、最終的に高品質コードの最も重要な利点であるその包括性を排除すること。
取引システムを作成する場合、1秒間に最大100,000件のリクエストがネットワークを介して送信され、取引戦略が2日ごとに開発および実装される場合、コードの単純さは単に望ましいものではありません。 したがって、このようなシステムを開発するときの私の「1分間のルール」：
1分以内にこのC ++ファイルの機能を理解できない場合は、コードが間違っていると考えてください。
本当の理由
しかし、私が非常に成功しているという事実にもかかわらず、現代のC ++を扱うことをほとんど止めた本当の理由は、本当に注目されるべきIT業界でますます多くの開発が現れているということです。
C ++はFortranのようになり、限界に達しました。 現在、すでに非常に高速なインターフェイスが存在するため、「クロックサイクル」という概念はシステムの特定のノードには無関係になります。 速度は、隣接するワイヤのペアを介して正確に同時に送信された2ビットの情報が、1メートルも通過していないために同期していない可能性が高い値に達しました。
C ++は、GPUなどの最も並列化されたシステムであっても、もともと一貫性のあるデータ転送方法を指向していたため、現在市販されている最新のプロセッサに実装されている速度の制御には適していません。
最新の開発者は、本当に最新の状態を維持したい場合、新しい言語（VerilogおよびVHDL）を使用せざるを得ません。 彼は自分のプロセッサとマザーボードの仮想モデルを設計できなければなりません。そうでなければ、今後数年間の技術的成果の雪崩に対処できません。 そして、PPVM（ Field Programmable Gate Array 、 FPGA ）が超高速を特徴とするわけではありません-これはそうではありません。 実際、それらはトッププロセッサよりも桁違いに遅いです。
ちょうど今、ますますさまざまな再構成可能なコンピューティングシステムがあります。 たとえば、IntelはXeonプロセッサに組み込みのPPVMを提供し、 モノのインターネット（ IoT ）は今後5年間で10億ドルの市場になり、小さな10ドルのPPVMをプログラムする資格のある技術者の軍隊を雇う必要があります。 そして私を信じて、RTLレベル（ レジスタ転送レベル ）でのプログラミングは、C ++でコードを書くよりも数百倍難しいです。 また、C ++の学習が容易でない場合は、プロレベルでPPVMプログラミングを習得することを想像してください（アルテラのTransceiver Toolkitのドキュメントだけで700ページ、別の1000のQuartus開発環境、およびザイリンクス製品が必要です）。
それでも、それは価値があります。 最終的にこれらの新しい言語とテクニックを習得すると、自分のアイデアを具体化するための最大の機会が開かれます。 これが、「ユニコーン」の誕生です（ 短時間で推定コストが10億ドル以上になる新興企業-約Transl。） -全体像を見ることができる人々に感謝します。
おわりに
そうかもしれないが、C ++言語は徐々に過去のものになりつつあると思う。 Fortranの場合と同様に、Fortranの時代は感じられます。 したがって、現代のC ++でプログラミングスキルを向上させるために時間とエネルギーを投資することは、CobolまたはFortran自体に投資するようなものです。 新しい時代のプログラマーは、今後数十年に登場する高度なテクノロジーに対処するために、新しいツールを習得する必要があります。 そして、これらすべてを研究する時間は短すぎます。
翻訳者のメモ
著者の意見には完全に同意しませんが、C ++プログラマーはこの記事を読むべきだと思います。 また、現代のC ++では、何かがおかしいと感じています。 テンプレートの「派手な」コードを理解するのは非常に難しくなり、さらに、約束された効率が得られません。 一般的に、私はクラスを使用してCスタイルのコードを書くことにますます傾いています。
そうそう、私はほとんど忘れていました。 静的コードアナライザーを使用して、 愚かなエラーの数を減らすこともできます。エラーがなければ、C ++で頭痛がします。