C++: ドキュメンタリー: 世界で最も重大なプログラミング言語

 (herbsutter.com)
5 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Bell Labsでの始まりから世界的な採用、そして現在の成長傾向までを1本にまとめたC++ 40年史ドキュメンタリーで、C++の歴史、標準化、ツールエコシステムに参加した人物たちが出演
  • C++ は、Bjarne StroustrupがBell LabsでCのハードウェア制御力とSimulaのオブジェクト指向抽象化を組み合わせるために作った C with Classes から出発し、大規模システムのための効率的な抽象化言語へと成長
  • 初期実装 CFront はC++をCコードへ変換し、既存のCインフラとライブラリをそのまま使えるようにしたことで、1983年以降ユーザーが増えるにつれ互換性が中核課題として浮上
  • IBM、HP、Sunの圧力をきっかけに始まった ANSI/ISO標準化 は、ベンダーごとの実装分裂を防ぎ、1997年の標準にはnamespace、exception、template、STLが含まれた
  • 2000年代初頭にはJavaとC#、ドットコム崩壊、CPU性能の急速な向上によって C++ winter が訪れたが、2004年ごろに周波数スケーリングが止まり並列性が重要になると、C++11がルネサンスを生んだ
  • 今日のC++は、CERN、ゲーム、金融、CUDAベースのAI・HPC、組み込みシステムなどで使われており、メモリ安全性、複雑性、標準委員会の規模、資金不足が主な課題として残っている

Bell Labsで始まった C with Classes

  • C++は40年以上の歴史を持つ言語であり、最初に作られた当時は、エディタ、構文ハイライト、コード探索、自動補完、リファクタリングといったツールがなく、多くの開発者はBASICやチップごとに異なるアセンブリ言語を使っていた
  • より大きく複雑なプログラムが必要になっていた時期に、Bjarne StroustrupはBell Labsで分散システムを作ろうとしており、デバイスドライバ、ネットワークインターフェース、メモリマネージャ、プロセスのような要素を扱うには低水準言語が必要だった
  • Cはハードウェアを完全に制御でき、システムプログラミングに適していたが、プログラムが大きくなるにつれて、モジュール、通信チャネル、プロトコルのような構造を表現するには不十分だった
  • StroustrupはCambridgeで使ったSimulaの強い型安全性、ユーザー定義型、クラス、クラス階層を気に入っていたが、Simulaは遅すぎてメモリ消費も大きいと考えていた
  • そこでSimulaの基本機能をCに入れる形でC with Classesを作り、その後ほぼ40年にわたり、C++をSimulaとCの両方ができることをすべて実現する方向へ発展させていった

CFront、名前、初期の普及

  • C with Classesは当初Cプリプロセッサの形で作られたが、ほかの人々が使い始めると、StroustrupはCとの差が十分ではないと判断し、1年間をコンパイラと言語の改良に投じた
  • CFrontは従来型のバックエンドで機械語を生成するのではなくCコードへコンパイルし、C++利用者が新しいインフラやライブラリをすべて導入しなくても既存のC環境を維持できるようにした
  • CFrontは1983年に作られ、字句解析、構文解析、型検査、木構造表現の生成、木構造最適化を行う本格的なコンパイラだった
  • C++という名前は、Cの ++ 演算子が増加を意味することに由来し、意味としては ++C が正しいが、索引や参照のしやすさからC++になった
  • AT&Tはコンピュータとソフトウェア事業へ参入しながらC++コンパイラの販売を試みたが、ハードウェアは十分に売れず、初期のC++実装はテープ代と低い商用利用料という水準で、事実上広く配布できる状態にあった
  • Stroustrupはしばらくの間、文書、コンパイラ、言語実装、ヘルプデスクをすべて担当しており、AT&Tの投資は非常に小さく、一度は汎用プログラミング言語の普及に3年間で5,000ドルしか割り当てられなかった
  • CFront 2.0では多重継承処理のバグが見つかり、すでに約束された中核機能が現場に出ると直せない形で壊れかねなかったため、数日以内に修正版を作って配布した
  • 同じリリース番号を維持しなければならなかったため、バージョンは2.0.1ではなく2.0.0として配布され、互換性は冗談めかして「C word」と呼ばれるほど支配的な要求となった

標準化とSTL

  • C++はAT&T内部の生産性向上ツールだったが、単一企業に閉じた言語では成功できず、外部開発者とライブラリエコシステムが必要だった
  • Web以前は、Usenetの comp.lang.c++ のようなグループやByteのようなコンピュータ雑誌が情報拡散の経路であり、Stroustrupは1980年代後半にさまざまな企業や組織で講演しながら言語を広めた
  • 広告キャンペーンや強力な後援者がなくても利用は増えたが、Borland、Microsoft、IBM、Sunなど複数のベンダーがそれぞれ独自のC++実装とtemplate設計を作ったことで、コード互換性は深刻に分裂した
  • IBM、HP、Sunを代表する人々はStroustrupにANSIルールの下でのC++標準化を求め、Stroustrupは時期尚早だと考えたが、最終的には1年後に標準化の基礎文書を作ることにした
  • Annotated Reference Manual、すなわちARMは標準化入力文書となり、template、exception、namespaceのような機能を含む方向へとつながった
  • 標準はC++コードを書く人とC++実装の間の契約として定義され、複数ベンダーが同じコードを同じ意味で受け取れるようにする仕組みとなった
  • Alexander Stepanovが作ったSTLは、アルゴリズムを適用可能なすべてのデータ構造で動作させ、データ構造同士が互いにデータを受け渡せるようにすることを中心理念としていた
  • STL以前は、それぞれがarray、list、tree、container、アルゴリズムのやり方を作っていたが、STLはアルゴリズムとコンテナを定義する1つの強力な方法を提示した
  • STL提案は標準化日程の上では遅すぎ、規模も大きすぎるという反対を受け、Microsoftなど主要企業も反対したが、発表と議論を経て委員会の約80%が賛成し、標準に採用された
  • C++は1997年11月に標準化され、namespace、exception、template、Standard Template Libraryが主要な基本機能として追加された
  • LLVMはこの標準化以後に始まったため、以前のコード移行負担なしに新機能を意図された形で使うことができた

冬の時代とC++11ルネサンス

  • C++は1990年代に、CERNのような高エネルギー物理ソフトウェアとコンピューティング分野でFortran中心の開発を変える言語となり、既存のライブラリやコードはC++へ移植されたり、C++向けに作り直されたりした
  • ゲーム開発では、ビデオカードとAPIが低水準処理を担うようになり、CやアセンブリからC++へ移る流れが生まれ、UnrealのようなエンジンエコシステムでC++が使われた
  • 金融では、プログラム売買と高頻度取引の登場によりマイクロ秒単位のレイテンシが重要になり、C++はすべての行を細かく最適化しなくても低レイテンシを得られる言語として使われた
  • 2000年のドットコム崩壊とともに、JavaはSunの強力なマーケティングによって「未来の言語」「インターネットの言語」として台頭し、JavaはC++の複雑さへの明確な反応として登場した
  • Microsoft内部では、Visual Basicの簡単なフォームベース開発とC++の性能・表現力を組み合わせたいという欲求があり、その結果C#が作られた
  • 2000〜2005年の間は単なる停滞ではなくC++の衰退期があり、CPU周波数が上がり続けていた時代だったため、多くの言語設計者や開発者は性能をそれほど重要視しなくなっていた
  • 2004年ごろ、プロセッサ周波数スケーリングが終わり、単一コアの性能・電力限界と命令レベル並列性の収穫逓減が現れたことで、ハードウェアが自動的にプログラムを速くしてくれる時代は終わった
  • マルチコアと並列性が重要になったが、当時のC++標準にはthreadingがまったくなく、Herb Sutterの「C++ multi-threading: is the standardization committee listening」というメールがこの問題を浮き彫りにした
  • C++0Xは2002年に始まり、2007〜2009年の完了を目標としていたが、重要機能をさらに盛り込むため遅延が重なり、最終的に13年かかった
  • C++11はmove semantics、concurrency、auto、range-based for loop、smart pointer、lambda、constexpr などを導入し、C系言語の中でthreadingを正式に扱った最初の標準となった
  • C++11は、より簡単で安全な言語機能への需要と、ハードウェア性能を最大限活用しようとする必要性が同時にかみ合ったことでルネサンスとなった
  • その後、決まった時期に標準を出すtrain modelが導入され、委員会は2年周期ではなく3年周期を選んだ
  • C++14はC++11に入れられなかった項目とバグ修正を含む小規模リリースであり、C++17とC++23では多くの言語機能と標準ライブラリ機能が追加された

現在の規模と課題

  • C++は複雑性が増し続けており、変数初期化の方法がいくつもあるという批判や、「理解しにくい複雑さ」という酷評を受けている
  • 標準委員会も拡大して527人規模となり、発足当時の全構成員数に匹敵する数の委員会と委員長が生まれているという懸念もある
  • 言語設計では追加はできても削除はほぼ不可能なため、何を入れるかよりも、いつ断るかが重要な問題になる
  • C++は電力生産、風力タービン、炊飯器、ボウリング場、ハリウッド映画、自動車、金融、カメラなど多様な場所で使われており、「だいたいどこにでもある」という表現も出てくる
  • HRTのC++コードベースは100万行以上、15,000ファイルで構成されており、2025年だけで約800人の開発者が84,000件のコミットを行った
  • ゲームではUnityがC#を使う一方、UnrealはC++を使っており、Call of Dutyのように高フレームレートと高速グラフィックスが必要なゲームは速度のためにC++を使う
  • NvidiaとアクセラレーテッドコンピューティングにおいてもC++は重要で、表面上はPythonを使っていても、実際の計算負荷は高度に最適化されたCUDAライブラリが担っている
  • 急成長する言語としてRustとC++が挙げられ、C++開発者は2022年の940万人から2025年には1,630万人へ増えたという数字が示された
  • 性能あたりの電力効率が重要な言語への需要が続いているため、C++は優れていて代替しにくい用途を確保している
  • 同時に、大手プレイヤーがAIへ移行することでC++への資金が減る可能性があるという懸念もある
  • パンデミック期間には、政府や規制機関で、基本的にメモリ安全性を提供しないC++から離れようとする動きがあり、メモリ安全性は解決すべき最重要課題として提示されている
  • C++26ではソフトウェア強化のため、未初期化変数はもはやundefined behaviorではなくなり、C++26標準ライブラリでは string、span、vector のような共通型にbounds safetyオプションが提供される
  • C++26のstatic reflectionは、プログラムコードがプログラムコードを見ることを可能にする機能であり、標準化された単一機能として最も影響力が大きい機能と評価されている
  • AIが言語安全性やプログラミング言語の使われ方に大きな影響を与える可能性はあるが、今後何が起こるかはまだ分からない、という結論で締めくくられている

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • Ken ThompsonがC++を一貫性がなく複雑なアイデアの寄せ集めだと批判した言葉はいまでも響く。仕事で使ったのはC++98が最後で、11/17/20は好奇心で少し触った程度だ
    c++/cfrontがCの後光に乗っていなければ広く使われたかは疑わしく、その点こそがアイデンティティであると同時に、C++が変えようとしなかった限界だったと思う。コンパイラが処理できたはずのことを、CoverityやValgrindのようなツールで実装を浄化するのに似たような時間を使うのは非常にいら立たしい
    C++98の時代にはBjarneの内部構造の本で何が起きているのかかなり理解できたが、その後は「effective, more effective, proficient, performant C++」系の本が一つの産業のように増殖し、LLMが出るまでは他人が書いた既存コードを理解できると期待するのをやめるしかなかった。むしろ問題領域を学ぶのに時間を使ったほうが満足できた
    それでもKernighanやStepanovのような好きな人物が出てくるので、このドキュメンタリーは見るつもりだ

    • あまり知られていない話だが、Zortech CをC++に拡張するか悩んでいたころ、AT&Tの知的財産権が気になってAT&TのIP弁護士Ryan Williamsに連絡したことがある
      C++コンパイラを作るのにライセンスが必要か、名前をC++ではなく別のものにすべきかと尋ねたところ、彼は笑いながら好きにしていいと言い、許可を求めてきたコンパイラ屋は私だけだ、ありがとうとまで言っていた。数年前に訃報を見たが、いい人だった
    • C++成功の足場となったのはZortech C++だった。当時のプログラミングの90%はMS-DOSで行われており、cfrontはDOSではほとんど使いものにならなかった
      コンパイルは苦痛なくらい遅く、ちょっとしたものではないアプリに必須だったnear/farポインタもサポートしていなかった。Zortech C++がその問題を解決し、飛ぶように売れて、C++の成功に必要な臨界質量を作った
      comp.lang.c++のトラフィックは急増し、Borlandは私たちの販売実績を見て自前のオブジェクト指向言語製品をやめ、代わりにTurbo C++を作った。MicrosoftもBorlandの成功を見て自前のC++を作った
      MicrosoftにもZortech C++コンパイラをたくさん売り、彼らはそれで      COM      を開発した。MicrosoftがC*という独自のオブジェクト指向Cを作っているという噂も聞いたが、確認したことはない
    • 見落とされがちだが、C++が存在したからこそCが生き残れた可能性は高い。C++がなければ、Cそのものにもっと多くの機能を入れろという圧力はものすごかったはずだ
      C委員会が長いあいだ多くを追加せずに持ちこたえられた理由の一つは、C++を指して「それは向こうの仕事であって我々の仕事ではない」と言えたからだ。C++がなければ、Cがクラス、テンプレート、ラムダを持つような言語になっていたのかもしれない
    • C++98はC++11ともかなり違う。BjarneのC++11の本は98版とはまったく別物のように読めた
    • Ken Thompsonや昔のUNIXの人々はとても尊敬しているが、現実世界は汚く、孤立した最善の解決策が常に勝つわけではないという点は、彼らも認めるのではないかと思う
      彼らが作ったCとUNIXも、より先進的だったLISPやSmalltalkのシステムに勝ったが、それは実装がより単純だったからだ。彼ら自身のより先進的なPlan 9ベースのOSでさえ、より広く普及したUnix系システムを押しのけることはできなかった
      結局のところ、配布力と「十分に良いこと」がいつも勝つように見える。Perl、Python、Ruby、JavaScript、PHPのような動的言語と、強力にマーケティングされたJavaが十分に良い高水準機能を提供したことで、人々はLispやSmalltalkに向かわなかったのだと思う
      この観点から見ると、C++は広く採用された低水準・高性能言語の上に高水準機能を載せ、広範な採用に十分な技術にした手段だったのかもしれない

  • 最近C++でかなり仕事をしているので、ビルドが終わるのを待つあいだに動画を見ることにした。長さがちょうどよく、ありがたいことに動画自体もとても良かった

    • C++の歴史について読めるものはできるだけ読んできたし、この動画にも期待している。C++が進化してきた過程は本当に興味深いと感じる
    • これが単なるネタ投稿なのか、それともビルドに実際1時間くらいかかるのか気になる。もしそうなら本当にとんでもない

  • 個人的には、C++は15年ほど使ってきた言語の中で最もエレガントな言語だ。「体系化する人」タイプで、自分が書いたものについて最後の1ビットまで極めて精密なメンタルモデルを持ちたいなら、C++に勝るものはない
    コンパイラなどに由来する限界や不確実性は認めるが、それでもそう思う

    • 何についての精密なメンタルモデルを指しているのか、例を挙げてもらえる？
    • 同じことはRustにも言えると思う
    • エレガントな言語とは、ごく少ないもので多くを成し遂げる言語のことだ。ForthとSchemeはエレガントな言語だ
      C++で働くのを好む自由はあるし、C++で多くを成し遂げられるのも事実だが、C++が「ごく少ないもの」でそれを実現していると見るのは難しい、という点に大きな異論はないだろう

  • このドキュメンタリーにAndrei Alexandrescuが含まれていてうれしい。彼の Modern C++ Design は読んだ当時、思考を大きく広げてくれた本で、今でもそうかもしれない。読んだことがある人はいる？

    • 彼の講演は私が最も好きな講演のいくつかだ。素晴らしい話し手で、引き込み方がうまく、ユーモアのセンスも抜群で、それをとてもうまく使っている
    • いまでも面白いが、Andreiの本は何年にもわたって私をC++から遠ざけることになった最後の一撃でもあった。本当に良い本だったし、同時に別の言語へ移りたいという気持ちを固めてもくれた。当時はGoだった
    • 同意する。Modern C++ Design はおそらく私のキャリアで最も多くを得たプログラミング書の一冊だ
    • 私も同じ感じだ。ミュンヘンのMeetupでAndreiに一度会って、あなたは私に考え方を教えてくれたと言ったら、会話が少し気まずくなった。それでも楽しい時間だった
    • 最近読んだ。いくつかの章は良かったし、とくにポリシークラスがオブジェクト指向設計の一部の問題をどう修正するかが興味深かった
      各章をAIチャットボットに要約させて、現代的な対応物が何かを尋ねることを勧める。いくつかのイディオムはすでに改善されており、ある節全体はstd::variantとstd::visitの使用に置き換えられているようだった

  • C++は消えるべき。多くの人が投資し、膨大なコードがC++で書かれてきたことは理解している。昔はファンだったし、今でも主な業務言語だが、2026年にLLMがあらゆる脆弱性を見つけられ、攻撃者も増える状況では、安全性がデフォルトの言語が必要だ
    C++は安全性を得るには選択的に有効化し、極度の警戒が必要な言語だ。うまく機能しておらず、数十年の経験がそれを証明している

    • では何に置き換えるべきなのか？
    • LLMがソースコードなしでもあらゆる脆弱性を見つけるなら、コードがあるときはもっと簡単に見つけられるのでは？
    • C++は当時としては素晴らしい言語だった。それほど強力な抽象化を提供しながら、これより速い言語はなかった。C++11でshared_ptrのようなものが入って、言語をどれほど大きく変えられるかも示した
      ほとんどあらゆるアイデアを取り込み、実戦で何が通用し何が通用しないかを学んだ。RAII、ムーブとコピーの区別、スマートポインタ、placement-new、ジェネリクスは残せる
      逆にauto_ptr、デフォルトコピー、特定の例外実装方式、多重仮想継承、コードを丸ごと置き換えるテンプレートは捨てられる。私の考えでは勝負は終わっており、Rustはうまく機能したものを最もうまく整理した結果だ。コンパイル時間まで受け継いだのはおまけだ

  • C++開発の流れが続いているのは驚きだ。ゲームやプログラムがC++で作られていると、たいてい性能がある程度保証されるのでうれしいが、直接C++を書けと言われたら泣きそうになる
    覚えることが多すぎるし、標準も多様すぎる。保守に入ったプロジェクトがC++だと、それだけですぐ気が重くなる。とにかく難しすぎる。他人が書いてくれるならいいが、自分で書きたい言語ではない

    • 個人的にはC++プログラミングがそこまで難しいとは感じない。欠点は頭のウォームアップが必要な点で、プロジェクトごとにやり直しになるが、いったんフライホイールが回り始めれば、ほとんど力をかけずにコードが書ける
      どの言語を使うにせよ似たようなウォームアップは必要なので、私にとってはPython、Go、Javaを書くのと大差ない
    • ゲームではC++はずっと単純な言語になる。ゲームのコードベースはたいていC++標準ライブラリをほとんど無視するからで、そうするだけの理由もある。たとえば[0]を参照
      標準ライブラリ抜きで見れば、C++はまあまあ悪くない
      C++エコシステムの主な問題は、誰もが自分なりの言語サブセットを削り出していることにある。だから単一のエコシステムではなく、互いに衝突するスタイルと言語／標準ライブラリのサブセットを持つ複数のエコシステムになっている。このせいで、ライブラリを通じたコード再利用が必要以上に難しくなる
      [0] https://hftuniversity.com/post/the-c-standard-library-has-be...
    • C++に機能が多いのは事実だ。だが別のところでも言われているように、ほとんどのプロジェクトは独自ルールと使用する機能サブセットを定めている
      機能集合が大きい利点は、C++が非常に低レベルから非常に高レベルまで優れた抽象化を使えることだ。インラインアセンブリ、ビット演算、直接的なメモリ操作のような低レベルも可能だし、ほとんどスクリプト言語のように高レベルにも使える。問題領域が何を求めようと、C++で対処できる
    • 言語の70%だけ知っていても、かなり生産的に使える。C++がゲームエンジンのような領域にしか向かないというのはよくある誤解で、アプリケーション領域でも十分に通用する
      ついでにプロフィール情報を見る限り、北朝鮮にいるのでなければ、単価に0をひとつ足したほうがいい。そうすれば、より長期的で品質の高い顧客を得られるはずだ
    • 趣味のひとつは中古店をあさって、過ぎ去った時代のダサい品物を眺め、出来の悪い現代のガラクタをふるい落とし、見つかれば単純で頑丈な道具に喜ぶことだ
      C++プログラマーとして生きるのは、まさにそんな感じだ

  • Web開発者を教えるたびに、インターネットの言語はJavaScriptではなく**C++**だと言っている。Web開発者は、C++開発者が作ったプログラムの中で遊んでいるユーザーにすぎない

    • そのたとえを続けるなら、ブラウザ開発者もC/OS/カーネルプログラムの中で遊んでいるユーザーにすぎない
    • 私はWebとインターネットを別物として見るほうだ。Webの言語を挙げるなら、おそらくHTMLだろう
      インターネットの言語が何かは、ずっと曖昧だ

  • 自分が情熱を持っているテーマの無料ドキュメンタリーは本当にいい。ありがとう
    ただ私は少し変わっていて、人々が短い文をつないで話す形で作られたドキュメンタリーは見ていられない。「彼らに物語らせる」という意図はわかるが、気が散るので、何を考えるべきかを示してくれるナレーターが必要だ
    それでも制作者たちには好意を持っている

  • 最近の流れを追えていなかったが、このところPython、Clojure、そしてたぶん他の言語のドキュメンタリーもあった。同じ人たちが複数の言語を扱うシリーズを作っているのか？ 偶然か？ それとも今は、あらゆるプログラミング言語が自前の映像ドキュメンタリーを作ろうとする流れなのか？

    • そう、同じ人たちが作っている: https://www.cultrepo.com/
      オープンソースソフトウェアに関するドキュメンタリーを作っているようだ

  • この話題についてはChandler Carruthの興味深い考えがある: https://hachyderm.io/@chandlerc/116694268329657881

    • 一理ある。映像はたしかに賛歌に近く見えたし、批判的な声が足りないとも感じた
      最後の10分になってようやく、肥大化する複雑さやメモリ安全性のような定番の批判に少し触れていた。それでも楽しく見られた