C++の初期の頃、メモリ安全性の問題（バッファオーバーフロー、ダングリングポインタ、use-after-free）は 広く知られていた ものの、言語レベルでの修正が必要な緊急の欠陥とは見なされていませんでした。なぜでしょうか？
1. パフォーマンスが王道だった
C++は1980年代にCの強力な進化版として登場しました。開発者に以下をもたらしました：
- メモリへの直接制御
- オブジェクト指向プログラミング
- ゼロコスト抽象化
この制御は、非常に高速なアプリケーションを意味しました。メモリバグ？それは開発者の責任と考えられていました。その考え方は： 「力には責任が伴う。もっと良いコードを書けばいい」 実際、C++は開発者に以下を提供します：
- C++は開発者に メモリへの直接アクセス、 手動のリソース管理、 低レベル制御、そして 微調整されたパフォーマンス最適化になり得ます。
- しかし、これは言語が 手取り足取り教えてくれないことも意味します。バッファオーバーフロー、二重解放、ダングリングポインタのような危険なミスを防いではくれません。
- つまり、 責任 は 開発者 にあり、正確で安全かつ効率的なコードを書くことが求められます。
2. 開発者はハードウェアに近かった
当時、ほとんどのC++開発者はシステムプログラマーか、ハードウェアに近い場所で働いていました。彼らは メモリを深く理解していた 。malloc、ポインタ、スタックとヒープ。安全網は期待されてもいなければ、望まれてもいませんでした。
3. セキュリティは中心的な関心事ではなかった
80年代と90年代には、セキュリティの脅威は今日のような広範な影響を持っていませんでした。メモリリークやオーバーフローは主に バグや安定性の問題と見なされ、 リモートコード実行のベクター やデータ窃取の手段とは考えられていませんでした。
4. ツールがまだ存在しなかった
静的解析ツール、ファザー、ASanやValgrindのようなツール？それらは存在しないか、極めて限定的でした。微妙なメモリの問題を早期に検出するのは容易ではありませんでした。その結果、ほとんどのチームは早期に検出できませんでした。
現在へ：なぜ今、私たちは気にするのか
今日、 ソフトウェアはすべてを動かしている 。車、飛行機、ペースメーカー、金融システム。メモリの脆弱性は単なるクラッシュではなく、 サイバー攻撃や壊滅的な障害になり得ます。
意識の高まりとともに、以下のような取り組みがあります：
- Microsoftによるメモリ安全な言語への推進
- Rustの台頭
- GCC/Clangのセキュリティ強化フラグ
- GoogleによるCarbonとメモリ安全なC++サブセットの取り組み
……業界はようやく、数十年間潜んでいたリスクに追いつきつつあるのは明らかです。
今後は？
初期のC++哲学は、力、パフォーマンス、柔軟性を優先し、安全性は優先しませんでした。それは その時代には理にかなっていました。しかし世界は変わりました。今、私たちは「モダンC++」が何を意味すべきかを考え直しています。単に速いだけでなく、設計によって より安全 であるべきです。
最近、C++の生みの親であるBjarne Stroustrupは、政府機関や業界リーダーからの言語のメモリ安全性に関する監視の強化に対応して、C++コミュニティに行動を呼びかけました。この監視には、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）と国家安全保障局（NSA）の勧告が含まれ、組織に対してCやC++のような言語から、Rust、Go、Javaなどのメモリ安全な代替言語への移行を推奨しています。
今の問いは、C++が近いうちに設計によって安全性の問題に対処するのか、それともRustのような言語がC++が伝統的に支配してきた領域で地盤を広げ続けるのか、ということです。