C++は本当に面白い
(learncodethehardway.com)- C++はC++11以降、言語とエコシステムが大きく変わり、自分で作って実験する過程の中でプログラミングの楽しさを取り戻せる言語になった
- かつてのC++は、テンプレートメタプログラミングの過剰さと標準・パターン中心の文化のために、多くの開発者にとって疲れる言語として記憶されていた
auto、nullptr、range-for、ラムダ、<chrono>、スマートポインタ、<thread>のような変化が、C++のコーディングスタイルを大きく変えた- 最新のC++は、ファイルシステム、パッケージ管理、GUI/TUI、グラフィックス、数学、AI、OS APIへのアクセスまで選択肢が広く、作りたいものを自分で実装しやすい
- コンパイラエラー、ビルドツール、標準準拠、歴史的な複雑さ、RAIIといった欠点は残っているが、創作の可能性がその不便さを上回る
C++が再び面白くなった理由
- 小さなローグライクゲームを作る中で、マップ生成にDijkstraアルゴリズムを使って部屋をつなぐトンネルを実装したが、その過程でC++が実験の大きな妨げになることはなかった
- FTXUI のユーザーインターフェースを SFML のレンダーウィンドウに直接描画する実験も可能で、その過程でC++のUnicode処理も学べた
- こうした作業は簡単ではなかったが、実際に実現可能であり、「このアイデアは本当に動いた」という感覚がC++の面白さを生んでいる
- そもそもプログラミングを始めた理由は、億万長者にもっと金を稼がせるためでも、レンダリングエンジンと格闘するためでも、オープンソースプロジェクトの上層部を満足させるためでもなく、アイデアを実装する楽しさにあった
テンプレートメタプログラミング時代の疲労感
- 1990年代末から2000年代初頭にかけて、C++にはテンプレートメタプログラミングをあらゆるものに適用しようとする空気が強くあり、この時期がC++をつまらなくした転換点として扱われている
- テンプレートで2つの数を足す方法が直接足すより速いというような議論もあったが、実際のアセンブリ出力は同じだったという例が紹介されている
- C++標準委員会がプログラマに優れた使い勝手を提供することに消極的だった、という認識も否定的な体験を強めた
- 当時のC++は、
<>の山括弧と複雑な文法ばかり多く、得るものは少ない言語として記憶されている - Javaも当初はガベージコレクタと開発者フレンドリーさで魅力的に見えたが、その後はボイラープレートとデザインパターンの過剰さによって似たような疲労感を生んだ
C++11が変えた言語の感覚
- C++11に追加された機能 は、C++の印象を大きく変えた変化として評価されている
- 主な機能は次の通り
auto: 同じ型名を何度も書く負担を減らす自動型推論キーワードnullptr: CのNULLの問題を補うヌルポインタ表現range-for:autoと組み合わせることでコンテナ走査をより簡単にするループlambda expressions: API設計と使い勝手を大きく変えうるラムダ<chrono>:100msのような表現が可能な型安全の時間ライブラリ<regex>: 標準ライブラリに含まれる正規表現機能unique_ptr,shared_ptr: 所有権と参照カウントを扱うスマートポインタ<thread>: マルチスレッドを基本的な言語エコシステムに含めた機能
- C++11は従来のやり方を捨てることなく、言語の哲学とスタイルを変えたという点で、JavaScriptのES6に近いものとして受け止められている
現代C++エコシステムの選択肢
- 最新のC++は、他の言語で期待される機能の多くを備えている
- 例として挙げられているツールとライブラリは次の通り
- ファイルシステム走査:
filesystem - パッケージ管理: Conan, Meson WrapDB, vcpkg
- 行列ライブラリ: Eigen
- AI: TensorFlow C++ API
- グラフィックス: SFML
- GUI: Qt, wxWidgets, ImGui
- TUI: FTXUI
- ファイルシステム走査:
- エコシステムの品質には項目ごとの差があるものの、JavaScriptやPythonで経験したものより全体として高く評価されている
- 特にFTXUIとSTLは、優れた設計と使いやすさを示す例として挙げられている
「面白さ」を生む広い実装可能性
- C++が面白い理由は、単にモダンな機能が追加されたからだけではなく、ほとんど何でも作れるという実装可能性にある
- デスクトップアプリは fenster、SFML、Qt を使うことも、OS APIを直接扱って作ることもできる
- サウンドについても、SFMLのような手軽な選択肢から Wwise のような商用ツールまで幅広い
- 3DグラフィックスにはOpenGL、Vulkan、Direct3D、Ogre3Dなど多様な選択肢がある
- 数学分野には BLAS、Eigen、GMTL のようなライブラリがある
- 必要なライブラリがなくても、CまたはC++ ABIやOS APIに直接アクセスして作ることができ、その自作の過程自体が面白さの一部になる
流行から外れた言語の創作の自由
- C++は言語とエコシステムの品質が高い一方で、現在の流行語ではないため、言語を駄目にする類いの関心を比較的受けにくいという評価がある
- C++コミュニティは、何を作るにしてもあまり干渉しない雰囲気として描かれている
- 行列ライブラリ、GUIライブラリ、ゲームエンジン、妙なゲームのようなプロジェクトを自由に試せる
- 創造的な作業には、まずアイデアを外に出す段階と、その後に冷静に批判して品質を高める段階の両方が必要である
- 他の言語では、組織、リーダーシップ、コミュニティからの圧力が、創作途中の実験を妨げると評価されている
- C++の広い可能性と、比較的恥をかかせにくい文化が、創造的な体験を生みうる
cppreference.comの強み
- cppreference.com は、これまで使ってきたプログラミング言語のドキュメントの中でも最高水準と評価されている
- 長所は次の通り
- すべてのキーワードとライブラリがリファレンス文書として整理されている
- ほとんどの項目に実際に動く例がある
- 各機能が導入されたC++標準のバージョンが示されている
- 標準文書や関連する参考資料にリンクされている
- DuckDuckGoベースの検索ボックスがあり、スペルを間違えたり正確な用語を知らなくても探しやすい
- Copy elision のような重要概念も例とともに説明されている
- 不足している点は、さまざまなプラットフォームでコンパイラをインストールする方法がないこと
- C++コンパイラやプラットフォームの数はそれほど多くないため、導入ガイドを追加する余地もある
それでも残るC++の問題
- これはC++が完璧な言語だという意味ではなく、他の言語と同様に不便な点も多い
- WindowsでMicrosoft以外のインストール経路を使ってコンパイラや開発ツールを構成するのは難しく、そのために PowerShellインストールスクリプト を自作した
- 現在感じている主な不便さは次の通り
- コンパイラのエラーメッセージの95%以上は業界最悪レベルと評価されている
- ビルドツールは使いにくく、Meson でさえインストール済みパッケージの指示を無視して壊れたシステムライブラリを使う問題に遭遇した
- コンパイラベンダーに標準準拠を徹底させるインセンティブが乏しい
- C++は歴史的経緯から非常に複雑で、古いヒープ確保・raw pointerスタイル、テンプレートメタプログラミングスタイル、C++11以降のスタック中心スタイル、
struct中心のさらに新しいスタイルが共存している - RAIIは現実的な設定作業では邪魔になることが多く、他言語的な初期化コンストラクタと現在のRAIIとの中間地点が必要だと見ている
- こうした欠点があっても、C++の不便さは面白さを壊すほどではなく、C++は過去の山括弧とポインタ中心の言語という印象とはすでに異なっている
- FTXUIのGUIレイアウトコードは、C++だと知らなければ別の言語に見えるほどモダンな文法を示す例になっている
1件のコメント
Hacker News の意見
C++ 嫌いに近いが、それは信頼性が求められる業務コードを、まったく信用しがたい同僚たちと一緒に C++ で扱わなければならないのが嫌だからだ
個人プロジェクトでは、これまで経験したコーディング環境の中でもかなり満足度の高い部類で、実行を非常に細かく制御できる点は本当にワクワクする
約10年前に C++ から離れ、戻るつもりはないが、最近の自分のプロジェクトでは長期的な信頼性が最重要なので Rust + CI/CD がちょうど合っている
それでも、プログラムが自分の意図したとおりに実行されるよう設計・実装し、それが自分の専門性と洞察のおかげだと感じられる高揚感は恋しい
一緒に働く人にそういう動機で動いてほしいかと言われれば絶対に嫌だが、個人的には忘れられない楽しさだ
ビルドシステムとパッケージ管理は悪夢で、プリプロセッサはサディスティックな冗談のようで、構文はひどく、ランタイムには自分の足を機関銃で撃たないために何年もの経験が必要な残滓が多すぎる
だがある意味では、こうした苦痛が、知性と血の涙で包み込んだ実行ファイルをついに吐き出すときの喜びをさらに大きくしてくれる
C/C++ を数年間仕事で使っていたが、また戻りたいとは思わない
他人のコードをデバッグし、曖昧な統合問題に悩まされ、ビルドシステムのスパゲッティを動かすのにあまりにも多くの時間を費やした
この10年でテック業界はこの考えを失ってしまったように思うし、最高の人材をおいしい食事と柔らかい椅子のある大人向けの牢獄に入れている大手テック企業のせいだと思っている
スタートアップも以前ほど楽しくなくなり、VC 業界が狭い思考の窓を助長した結果、同じものを作るクローンスタートアップや流行が多すぎるようになった
新しいプロジェクトごとに C++ を使う理由は、自分で作る必要があるときに作れるという確信があるからだ
フレームワークは、特にプロジェクトの核心部分を扱うとき、望むとおりに動かないことが多く、使い続けたくなくなる
自分で作れるなら自分で作ればいいし、そうでなければフレームワークを使えばいい
自分で作れるなら、C++ は何でもでき、重要な面では邪魔をしない優れた道具だ
Rust のような言語は、私が危険なことをしていると文句を言うかもしれないが、C++ では頭の中のモデルを直接表現できる
ときにはポインタで考えることもあり、ポインタは本当に優れた道具だ
楽しさを取り戻そう、私生活だけでなく仕事でも
この記事はやや混乱しているように見える
多くの点に触れているが、それがなぜ C++ のほうが楽しい、あるいは楽しくないという結論につながるのかをくみ取るのが難しい
モダン C++ を極めて高品質だと言いながら、同時に広範なレガシー問題やひどいツールについて語っているのも混乱する
unique_ptrは素晴らしいと言いながら RAII は本当に嫌いだと言い、メタプログラミングは昔はどこにでもあったが今はそうではない、という主張も奇妙だconceptsを見るとそうではないし、C++ には最高のグラフィックライブラリがあるという話や、Python のインストールは C++ より難しいという話も、論旨とはあまり関係のない著者のこだわりに見える結局、著者は個人的な要因の複雑な組み合わせによって C++ を楽しいと感じているようで、それ自体は構わない
性能や技術的な性格のために C++ で最も楽しくプログラミングしたこともあるが、実践的なソフトウェア開発では、私たちが知っている多くの理由から C++ はあまり良くない
C++ は数十年分のレガシーと政治に傷ついた、深く矛盾した言語であり、C++ の現実を無視することが C++ 論議における最大の誤りだ
最近の C++ に対する私の態度は疲労感に近く、ここ何年も C++ が投げてきた障害をこれ以上飛び越えたくない
もうとっくに死んだ馬を叩き続ける必要はなく、C++ はただ C++ のままにしておけばいい
私には、記事が混乱しているというより、著者が楽しんでいて、その喜びをできるだけ分かち合おうとしているように見える
きちんとした論説というより、積極的に説得しようとする文章ではなく、「あえて説得されなくても共感できるなら、あなたも楽しめるかもしれない」というものに近い
商業的な仕事で現実に打ちのめされて疲れた立場なら、筋が通らないと感じるのも十分理解できる
私も最近、よりによって JavaScript を使ってものすごく楽しんでいるが、同じような記事を書いたら、この10年の商業的 JavaScript に疲れた人には同じくらい悪く読まれそうだ
それでも、著者が楽しんでいて、その楽しさを共有することにしたのは喜ばしい
C++ プロジェクトでサードパーティ依存関係を Linux/Windows/macOS で動くよう静的リンクするのに3日を費やした
そのパッケージは conan/vcpkg にはなく、奇妙な Makefile/cmake の組み合わせがある GitHub リポジトリだけだった
cmake/cpp の専門家とはほど遠いが、ほとんどの現代的な言語では
pip install、cargo add、npm install、go getのような方法で問題にならないC++ の意味論の細部を本で最初から最後まで読んだとしても、実際のプロジェクトで作業するのは依然として苦痛だ
結局 JavaScript 版 autotools のようなものにたどり着いたというのは驚きだ
他人のコードを静的ビルドしたり、別のプラットフォームでビルドできるよう変えたりするのは時に厄介だが、リンク自体は通常、include ディレクトリ、ライブラリパス、ライブラリ指定くらいのものだ
誰かが vcpkg/conan のパッケージングをしていないなら、pip/cargo/npm にもない可能性が高い
C++ で苦労したなら、他の言語ではさらにずっと大変かもしれない
ただし、歴史的な C++ の一部、特にビルドの話が非常に悪い状態にあることは、ここからも明らかだ
vcpkg にさえ入っていれば、インストールの難易度は他のエコシステムと正確に同じになる
定期的に C の代わりに C++ で作業してみるのだが、毎回似たようなパターンになる。
新しい C++ の技法を知り、何か良くなりそうだと思ってコードを書き、コンパイラエラーにぶつかり、その日の残りを、なぜ自分のやりたいことができないのか学ぶのに費やす。
たいてい C++14 に縛られていて、一部の問題は以後のバージョンで修正されているが、それでもやはりそうだ。
C++ を本当に好きになりたいのだが、理論上は生産性を高めてくれる、より強力な C を提供してくれる一方で、結局は認知的な負荷が大きすぎて、たいてい「クラス付きの C」を書いて済ませることになる。
2003年にはリアルタイム C++ をたくさん書いていて嫌いだったが、昨年はコードの大半を C++ で書き、ようやく好きになれた。
ラムダと
autoが、C++ を嫌いでなくなる転機だった。テンプレートも少し使ったが、主に同じ関数のバリエーションごとに大量の分岐を書かなくて済ませるためだった。
ラムダのおかげで、SICP 風の Lisp 系の先生たちから最初に教わったやり方でコードを書けるようになった。
unique_ptrを使うと、アロケーションも嫌ではなかった。そうではなく、まずコードをどう使うかを考え、そのうえで何らかの機能が問題を解いてくれるなら使うべきだ。
問題 → 解決策であって、その逆ではない。
たとえば C++ のテンプレートは概してひどいが、コンパイル時のダックタイピングや、
sizeof()に基づいてパディングを自動追加するようなものは、ときどき非常に役立つ。最初は C# プログラマーとして、組み込みプロジェクトのために C を学んでいたのだが、流れはまったく同じだった。
C++ には、アプリケーションにぴったりはまれば強力に見える素晴らしい機能がたくさんある。
しかし新機能を試すたびに、自分のやろうとしていることはいつもその状況では動かない境界ケースで、何時間も、あるいは何日も試した末に諦め、結局ただ C で書いていた。
もちろん Python や Ruby のように、この傾向から外れる言語もあるにはある。
たいていエラーテキストをコピーして、解読させている。
C++ は本当に面白いし、人々の不満は文脈に大きく左右されると思う。
多くの C++ 開発者はこの言語を嫌っているが、実際にはその嫌悪の向きが間違っていることがある。
実のところ、ソフトウェアをそれほどうまく扱えなかった人たちが作ったレガシー製品を相手にしている場合が多い。
自分も Rust で似たような経験をした。会社の既存の Rust プロジェクトに投入されたのだが、古いコードベースの中に互いに衝突する慣習がたくさんあった。
うまく合成できないエラー処理型、悪いクラス抽象化、不要な
unsafeブロックなどがあり、これまで担当したプロジェクトの中で最も苦痛だった。Rust のせいにするのは簡単だが、実際には単に悪いソフトウェア開発だった。
C++ に欠点があるのは確かだが、人々が感じる苦痛のかなりの部分は、どの言語で書いてもひどいものになっていたであろう悪いコードを扱っているからだ。
v[x]=yを書くたびに任意のメモリ破壊を招くわけではない。C++ の
std::optionalは、vが空のときに*vを呼ぶと未定義動作になる。optional の要点は空かもしれない値を保持することなのに、optional が空のときに最もよく行う操作に、なぜ未定義動作を入れるのか理解しがたい。
C++ をかなり使ってきた立場からすると、問題はプロジェクトのすべてのプログラマーが、100% の時間、100% 完璧でなければならない点だ。
メモリチェッカーや STL のデバッグモードを走らせることはできるが、リリースでもそれを走らせないなら、テストスイートが愚かな、あるいは悪意あるユーザーがやり得るあらゆる奇妙なことを突いてくれるのを期待するしかない。
ソフトウェアがこれほど重要になった時代に、Rust が C++ に近い性能を出せるように見えるなら、基本機能の多くを安全に使うのが非常に難しい言語を使う価値があるのか疑問だ。
しかも状況はさらに悪くなっていて、空の
std::functionの呼び出しは assert を投げていたが、新しいstd::copyable_functionはこれを未定義動作にしてしまった。型システムは苛立たしいし、だからといってまともなメモリ安全性が得られるわけでもない。
最も厄介な構文解析は本当に厄介で、ポインタの崩壊のような C から受け継いだ奇妙な点もそのままだ。
その上に
std::arrayのような新しい解決策を重ねながら、古いやり方をなくすことはできていない。実際のモジュールインポートシステムをまねようとしてプリプロセッサに依存し続けているのも問題で、そのせいでクラスコードの構成や pimpl イディオムのような回避策が付いてくる。
本質的に欠点があまりに大きく、多すぎるので、もはやその中に美しさを見つけるのは難しい。
一方で、単純な blub 言語のプロジェクトは、コードベースの状態に関係なく、かなり簡単に読み解けることが多い。
C++に楽しさを感じる人がいるのはいいことだけど、個人的には20年以上付き合った末に、もうC++は終わりにしたい
単にめちゃくちゃだ
本当に低レベル制御が必要なら欠点があってもCを扱うし、そうでなければRustやPythonなどのほうがずっと自分を幸せにしてくれる
それでもC++は残り続けるだろう
その言語で書かれたコードがあまりに多く、確実に身につけておく価値のある技術であり、かなり稼げる仕事もある
自分にとっては、言語があまりにも邪魔で、過度に複雑に感じる
「モダンC++」は素晴らしく、古いバージョンは学ぶ必要がなく、新しいバージョンごとにより単純になっている、という言説は知っている
問題は、実際に担当するコードベースがモダンC++ではないという点だ
これまでに出たあらゆる機能が使われていて、難しく、落とし穴だらけだ
何年も自分のプロジェクトだけでC++をやってきた人なら、ある程度の専門性を身につけて複雑さに耐性ができるかもしれないが、本当に良い言語ではない
中核的なデータ型や標準ライブラリなどを置き換えるようなやり方だ
特にC++20以降は、置き換えの基盤がかなりネイティブで表現力のあるものに感じられる
私が見る新しいC++プロジェクトのかなり多くは、この方向性を強く採っている
アプリケーションのためのシステムレベルのドメイン固有言語を簡単に作れることは、C++の強みだ
残念ながら完成できなかったが、覚えているのはクラス、
std::function、std::unordered_map、std::string、std::unique_ptrくらいだ似たスタイルでなければ、他人のコードを読むのは想像しにくい
大規模プログラムを職業として書いていないので、Visitorパターンのようなプログラミングパターンを越えるのが一番難しかった
C++はC++11で止まってくれればよかった
委員会はいま、あらゆるものを言語に入れたがっているように見え、C++はあらゆるニッチなプログラミングスタイルを支援する超巨大言語のように見える
だが面白いめちゃくちゃさで、私はC++で書くのが好きだ
ときにはそれが重要だ
Rustとの関係はずっと冷めている
Rustを尊重しているし、特に仕事のようにC++の使用を擁護しにくい文脈では、Rustが正しいと思えば使うし、Rustがやっていることは重要だと思う
しかし、これまでかなり多くのRustプロジェクトをやってきたにもかかわらず、書いていて退屈に感じる
本質的な面ではより優れているが、少なくとも自分にとっては楽しさが少ない
unsafeの封印を解けば整数をポインタへ明示的にキャストできるし、例えばメモリマップドI/Oでハードウェアを制御することもできるのでは？この記事は範囲の広い長い大演説で、「C++」という文字だけでも人々を刺激して、多くの部分が無視されかねない
自分も時々そうだ
不満は「It's Not All Puppies and Butterflies」の部分へ飛べばよい
著者はC++11に大きな感銘を受けていて、ほぼ20年にわたって意図的にC++を無視した後、私も似たように感じた
試して遊べるパッケージやライブラリを紹介してくれた点は良いが、それでも別のライブラリを自分のプロジェクトに入れるのは、しばしば苦痛だ
単一ファイルのヘッダーが思い浮かぶ
FTXUIは興味深い
そして本当にcppreference.comはすごい
Pythonのドキュメントもかなり良いが、cppreference.comほど良いドキュメントは見たことがない
Pythonのドキュメントはあちこちに散らばっていて、多くの箇所で不完全であり、一貫した文体編集スタイルも不足している
ただしDiataxisフレームワークの基準では、リファレンス文書だけでなく複数の種類の文書をかなりよく包含している
その文書を書く人たちは、このフレームワークを明示的に考慮しながら改善の方向を探っている
それでも、コード開発とほとんど同じように動く、ボランティアベースのオープンソース作業ではある
しばらく「システムにより近いところ」へ行きたいと思っていて、横でRustを学ぶのも簡単ではなかった
この記事を見ると、C++をもう一度身につければ可能かもしれないという希望が湧いてくる
さようならCMake……いや、たぶんMesonと言うべきかもしれない
才能あるチームが**モダンC++**をうまく使える状態で新しいプロジェクトを始めるなら、C++は素晴らしいという点に同意する
楽しく強力な言語で、性能がよく、複雑ではあってもデバッグと最適化は比較的直感的だ
約5年もののコードベースで働く機会があったが、C++11以降の基準で書かれていて、記事で述べられているいくつもの理由から非常に楽しかった
一方で、20〜30年かけて進化してきた古いコードベースや、腕の立つ人たちが保守していないコードベースなら、まったく別の体験になるだろう
21歳のとき会社が学費を出すと言ってくれたので、コンピュータサイエンスの学位課程に戻り、後に計算機科学へ変更した
「プログラミング入門」の授業初日にC++に触れた瞬間、恋に落ちた
当時使っていたPHP 7に比べて、型システム、デバッグ、エコシステムが素晴らしかった
マネージャーの許可を得て、既存のイントラネットアプリの一部にC++ベースのAPIを作り、PHPがWebSocketで呼び出すようにし、型システムと性能を活用できた
それらのシステムはいまも会社全体で毎日使われており、保守も問題ではなかった
IBM Pase for iというかなり特殊な環境で動いているにもかかわらず、そうだった
今はRustとAxumを使ってみた後なので、そういうAPIを作るときはRustエコシステムのほうをずっと好むだろうが、C++も評価されるべきだ
特にTypeScriptではないJavaScriptやPHPのようなWeb言語から来るなら、本当に素晴らしい言語だ
実際、思いつくいくつかの可能性、例えばC、Java、FortranよりはC++を好むと思う
例外はC#かもしれないが、その条件に入るほど古いのかは分からない
C++ に組み込みの正規表現が入り、かなり良いと言われる一方で、
std::regexは良いとは言いにくい性能が悪く、Unicode 対応も不十分なので、一般的には避けたほうがよい
std::regexを使わないよう強制しているC++ を学び、楽しみもしたが、深く入り込むことはなかった
いつも C のほうが好きだったし、もともと Dune のゲームエンジンや Unix ユーティリティのように、C をよりよく学ぶために読める最上級のコードベースも多い
最近 Rust を少し触ってみると、C++ を使う強い理由があまり見えない
関数型プログラミングに着想を得た強力な型システムと性能の組み合わせは打ち負かしにくく、ほぼ完璧な言語のように思える
それでも C++ を使わざるを得ないレガシーな理由は確かにあるはず
ゲームエンジン、組み込みプログラミング、別種のレガシーな結合といったものかもしれない
新しい C++ コードベースなら、かなりきれいに作ることはできる
ただ、この時点で新しいソフトウェアをなぜ C++ で作るのかは、あまり理解できない
C++ には面倒な点が多い
ライブラリ/パッケージ管理は標準化されておらず、ヘッダーはコードの重複であり、標準ライブラリは実装によって異なり、ほとんど読みにくい
標準には奇妙な挙動があり、人々は未定義動作に依存していながらそれに気づかず、初期化前の使用問題があり、所有権の問題や誤った参照カウントによるメモリリークが微妙に発生する
すべてをデフォルトではなく
constにしなければならず、noexceptを保証するには呼び出すすべてのものの例外を確認しなければならず、標準ライブラリの処理中のエラーは読みづらいオブジェクト指向色の強いコードは、実質的に技術的負債である
C++ の LSP は Rust のように抽象構文木を確認して定義を見つける構造的な方式ではないため、探索やコードベースの把握が遅い
Rust は
nostdを第一級のものとして明示的にサポートしているが、C++ で標準ライブラリを無効にするにはコンパイラごとのフラグが必要で、正しくできたか確認しにくいなので、組み込みだから C++ を使うという理由は、自分には説得力が弱い
Rust にも bevy のようなゲームエンジンはあるが、まだ新しく、望むなら Godot のスクリプティングに Rust を組み合わせることもできる
低レベルオーディオも Rust で同じように簡単で、単一のクレートでクロスプラットフォーム対応が可能
全体としては、レガシーコードと変化へのためらいが核心だと思う
ユーザー数、公開され利用可能な知識や資料、書籍、講義、ブログ、記事、動画、ソフトウェアライブラリ、そしてもう一つの巨大な言語である C との高い互換性まで含まれる
この分野に数年以上いる人にとっては、ソフトウェア業界の一般常識に近い
私は C++ をたくさん使ったことがないので、まともな初心者とも言いがたいが、以前に言語の生みの親である Bjarne Stroustrup や Scott Meyers などの古典的な C++ の本を買って読んで、ある程度理解したことはある
ただし C は、成功した商用製品を含め、数年間プロダクションでかなり使ってきた
https://www.stroustrup.com/applications.html
https://www.stroustrup.com
https://en.m.wikipedia.org/wiki/Bjarne_Stroustrup
https://en.m.wikipedia.org/wiki/Scott_Meyers
だからゲーム開発が最も長く C++ に残ると思う
0.001% のユーザーでセグメンテーション違反によりゲームが落ちたとしても、「だから何だ」という感じだ