エンジニアリング哲学：Bjarne Stroustrup、オーバーヘッドなき抽象化

要点

• オーバーヘッドなき抽象化。 Stroustrup は、明快なコードかベアメタルの速度かという誤った二者択一を終わらせるために C++ を築きました。表現力豊かに書いた版も、手作業で磨き上げた版も、同じ機械語にコンパイルされるべきなのです。
• ゼロオーバーヘッド原則。 「使わないものには代価を払わない。さらに、使うものについては、手で書いてもこれ以上うまくは書けない」——これが、すべての C++ 機能が通過しなければならない規則です。
• RAII がそれを具体化する。 リソースの寿命をスタック上のオブジェクトに結びつければ、ガベージコレクタなしで、決定論的かつ例外安全な後始末が手に入ります——後に Rust がほぼそのまま採用したパターンです。
• 下に余地を残すな。 C++ は、自身とシリコンの間にアセンブラ以外の何も挟まない最高水準の言語であり続けなければなりません。さもなければ、より低水準の言語がその座を奪うことになります。

原則

「使わないものには代価を払わない。そしてさらに、使うものについては、手で書いてもこれ以上うまくは書けない」——Bjarne Stroustrup、ゼロオーバーヘッド原則¹

この一文こそ、システムプログラミングにおいて最も重要なものであり、二つの約束を抱えています。前半が語るのは、抽象化は使わない時点では無償でなければならない、ということです。機能に触れれば何かしらの代価がかかるが、無視すればまったくかからない——メモリ1バイトも、実行時の1サイクルも。後半はより難しい約束です。抽象化を実際に使うとき、コンパイラは、その作業のために有能なプログラマが手で書いたであろうものに少なくとも匹敵する機械語を吐き出さなければならない。リリースビルドでは境界チェックを一切しないベクタ。生ポインタへとコンパイルされるスマートポインタ。生のループへと溶けて消えるイテレータ。明快さは無償なのです。

たいていの言語は取引を強います。遅い高水準で表現力のある版を取るか、読めない低水準で高速な版へ落ちるか——そして技芸の全体は、どの日にどちらの痛みを受け入れるかの選択へと成り下がります。Stroustrup の経歴の全体は、この取引への拒絶でした。彼はそれを身をもって感じていたのです。博士課程の学生だった頃、彼は Simula の抽象化を愛しましたが、それは実用には遅すぎました。BCPL の速度を愛しましたが、それは大きなものを築くには低水準すぎたのです。² C++ が存在するのは、選ばされるべきではないと彼が決めたからにほかなりません。効率と抽象化は、釣り合いを取るべき対立する二つのダイヤルではなかった。両者は同じ一行のコードのうちに、ともに到来するはずのものだったのです。

その信念は、パフォーマンスとは後から足す機能ではなく、失わずに済ませる性質であるという主張の根にあるものと同じです。ゼロオーバーヘッドな抽象化とは、遅い言語の上に築かれた速いものではありません。それは明快なものであり、コンパイラがそれを、あなたが手で書いたであろうものへとそのまま挽き戻すのです。だからこそ、明快さの代価を一度も払わずに済む。「私は自分のコードがエレガントかつ効率的であってほしい」と彼は言いました——そして肝心なのはかつという語です。彼は両者の間で選ばされることを嫌うのです。³

背景

Bjarne Stroustrup は1950年12月30日、デンマークのオーフスに生まれました。⁴ オーフス大学で数学とコンピュータサイエンスを学び、その後イングランドへ渡り、ケンブリッジ大学計算機研究所で博士号を取得しました。修了は1979年です。学位論文「分散コンピュータシステムにおける通信と制御」は、オペレーティングシステムの作業をコンピュータのネットワーク全体にどう分散させるかを扱ったものでした。⁴

その問題を研究するには、シミュレータを作る必要がありました。彼は最初の版を Simula で書きます。Simula は、クラスとオブジェクトを世界に初めて紹介したノルウェーの言語（Ole-Johan Dahl と Kristen Nygaard による設計）です。Stroustrup はこれを愛しました。Simula のクラス抽象化のおかげで、大きく入り組んだプログラムを、機械の都合ではなく問題の構造のとおりに組み立てられたのです——そして、そのプログラムは書くのも変えるのも喜びでした。ところが規模を上げて動かそうとすると、抽象化が自らのコストの重みで崩れ落ちます。実装は実用には遅すぎたのです。彼はシミュレータを BCPL、削ぎ落とされたシステム言語で書き直し、速度を取り戻しました——しかし BCPL はあまりに低水準で、それで大きなものを築くのは苦痛でしかありませんでした。² この激しい振れこそが、彼を形づくった傷でした。表現力のある言語を使ってはパフォーマンスでその代価を払い、速い言語を使っては他のすべてで代価を払った。どちらも受け入れられるものではない。両方の半分が、同時に成り立つべきだったのです。

彼はその不満を抱えて、1979年、ニュージャージーの Bell Labs へ移りました。そこで再び分散システムの問題に直面します——UNIX カーネルのトラフィックをネットワーク越しに分析する、というものです。ケンブリッジの記憶をたどり、彼は Simula の組織化する力を C に加えようと乗り出しました。C はすでに高速でハードウェアに近く、UNIX のシステム言語だったのです——そして C の速度を1オンスも手放すことなく。⁴⁵ 彼はその成果を 「C with Classes」 と呼びました。1983年、同僚の Rick Mascitti が C++ という名を提案します。C それ自身にインクリメント演算子を適用した名——一つ良くなった次の C、下の機械は同じ、というわけです。⁵

仕事

C with Classes から C++ へ：何のコストもかからない、より良い C

最初の一手（1979〜1983年）は、あえて控えめで、しかも的確そのものでした。C を取る——すでに高速で、すでにハードウェアへ直接対応し、すでに人々が信頼するシステム言語だった C を——そこに、Simula が彼に欲しいと教えたものを加える。クラス、より良い型チェック、データ抽象化です。⁵ 肝心なのは、それらをC プログラマが代価を払わなくてよい層として加えた点です。C のプログラムは依然として正当な C++ のプログラムでした。新機能を一切使わない struct は、これまでどおりの同じバイト列にコンパイルされました。新しい力はオプトインであり、それを使う代価は、同等の手書き C がかけたであろうコストだけ。これこそ、まだ名前を持つ前から存在していた、萌芽としてのゼロオーバーヘッド原則です。機能を使わない人々に課税してはならず、また機能が、彼ら自身が書いたであろうものより劣ったコードを生み出すことを許してはならない。

彼は『プログラミング言語 C++』（1985年）で言語を文書化し安定させました。これが C++ を広く世に出した本です。そしてその後、何十年もかけて、後続のあらゆる機能の設計を通じて言語の核を守り抜いたのです。⁴

ゼロオーバーヘッド原則

ゼロオーバーヘッド原則は、その荷重を支える中心思想であり、すべての C++ 機能が測られる基準です。Stroustrup はこれを二部構成で述べています。「使わないものには（時間でも空間でも）代価を払わない。そしてさらに、使うものについては、手で書いてもこれ以上うまくは書けない」¹ 前半は課税方針です——いかなる機能も、それを使わないコードにコストを課してはならない。後半は品質の基準です——実際に使う機能は、その特定の仕事のために注意深いプログラマが手で書いたであろうものに劣らないコードへとコンパイルされなければならない。テンプレート、constexpr、ムーブセマンティクス、そして標準ライブラリのコンテナとアルゴリズムは、すべてこれを守るよう設計されています。有名な二つの例外、実行時型情報と例外は、まさにコンパイラがオフにするスイッチを用意している二つの機能です。この規則を曲げているからこそそうなっているのです。⁶

その見返りは、アセンブリを目にするまでは不可能に聞こえるものです。表現力ある書き方と手作業で磨いた書き方が、同じ機械語を生み出す、という見返りです。

その同一性——表現力ある版と手作業で磨いた版が、一つの出力へと崩れ落ちること——こそ、この原則が技術的であると同時に倫理的でもある理由です。それはエンジニアの常套の言い訳を取り除きます。もし明快さが本当に高くつくのなら、「速くなければならないから」と醜く速い版を書くことを正当化できるでしょう。Stroustrup の賭けは、その言い訳がたいてい嘘だ、という点にあります——よく設計された抽象化は、読みやすい版かつ速い版を手にさせてくれる。なぜなら、それらは同じ版だからです。コストは一度だけ、言語の設計者によって払われた。だからこそ、プログラマが二度と払わずに済むのです。

RAII と決定論的なリソース

この原則には、システムプログラミングの最も厄介な部分のための機構が必要でした——取得され、その後確実に解放されなければならないリソース、すなわちメモリ、ファイル、ロック、ソケットです。ガベージコレクションはこれに、決定論を手放すことで答えます。後始末はいずれ、コレクタの都合で起きる——これはロックやファイルハンドルにとっては耐えがたいことです。Stroustrup の答えは、彼が RAII——Resource Acquisition Is Initialization（リソース取得は初期化である） と名づけたもので、リソースの寿命をスタック上のオブジェクトの寿命に結びつけます。⁷ リソースはコンストラクタで取得し、デストラクタで解放する。そして C++ は、スタック上のオブジェクトのデストラクタが、そのスコープを離れた瞬間に——通常どおりであれ、例外を通じてであれ、構築とは逆順で——必ず走ることを保証します。だからリソースは、解放されるべきときちょうどに、決定論的に解放されるのです。コレクタもなく、忘れるべき手動の free もありません。⁷

RAII は、ゼロオーバーヘッドを具体化したものです。デストラクタの呼び出しは、どのみち手で書かねばならなかったコードであり、言語はただ、それを忘れられないことを保証するだけです。自動的で、例外安全で、決定論的な後始末が手に入り、しかも後始末を自分で手書きしたとしても払ったであろうもの以上は何も払わない。これは、後続の言語——とりわけ Rust——がほぼそのまま採用することになる C++ のパターンです。

標準化と「より低水準の言語に余地を残すな」

Stroustrup は C++ を個人のプロジェクトのままにはしませんでした。彼はそれを標準化委員会へ持ち込み——1989年から ANSI、1991年から ISO——何十年も委員を務め、Evolution Working Group の議長となりました。C++ が一社の方言ではなく、安定したベンダー中立の標準となるためです。⁴ そして彼は委員会に、『C++ の設計と進化』に記した自らの設計原則から引いた、ひとつの憲法的な規則を与えました。「C++ の下に、より低水準の言語のための余地を残すな（アセンブラを除く）」⁸ その論理は厳密です——もし C++ とベアメタルのあいだにあるどこかの言語で、より効率的なコードを書けるとしたら、その言語が選ばれるシステム言語となり、C++ は存在理由を失ってしまう。⁸ 生き残るためには、C++ は C のハードウェアへの直接アクセス、データレイアウトの制御、そして機械と一対一に対応するプリミティブ型を保ち続けなければなりません。⁸ 抽象化とシリコンのあいだには、アセンブラ以外の何も座ってはならない。ゼロオーバーヘッド原則を、競争上の境界として言い直したものです——テーブルに何も残さない、その上で最高水準にある言語であれ、と。

方法論

その方法論は、ひとつの賭け——抽象化を正しく設計しさえすれば、明快さと速度は同じものである——を、一連の厳格な規則として強制したものです。

すべての機能をゼロオーバーヘッドに照らして測る。 いかなる機能も、それを使わないコードに課税してはならず、いかなる機能も、手書きの同等品より劣ったコードを生み出してはならない。これは、40年にわたって C++ へのあらゆる追加が通過しなければならなかった関門です。¹⁶

プログラマを信頼し、マルチパラダイムを保つ。 C++ が手続き型、オブジェクト指向、ジェネリック、関数型のスタイルを支えるのは、Stroustrup が、あなたの問題をどう組み立てるかを代わりに決めることを拒んだからです。言語は道具を与え、あなたが自分の領域を言語設計者よりよく知っていると見なすのです。⁶

ハードウェアへ直接対応させる。 プリミティブ型、データレイアウト、機械のあいだの C の一対一対応を保つ。抽象化は、それを隠すランタイムの上ではなく、金属の上に座るのです。⁸

後始末を、いずれではなく決定論的にする。 RAII はリソースの寿命をオブジェクトの寿命に縛り、解放が既知の瞬間に、例外安全に、ガベージコレクタもなく、解放を忘れるべきものもなく起きるようにします。⁷

それを公開の場で安定させる。 言語を所有するのではなく国際標準化委員会へ手渡す。C++ が永続する公共の標準であり、いかなる一社もそれをフォークできないようにするためです。⁴

影響の連鎖

彼を形づくった人々

Ole-Johan Dahl と Kristen Nygaard、Simula を通じて。 Simula は Stroustrup に、抽象化が何のためにあるのか——プログラムを問題の構造のとおりに組み立てさせること——を教えました。そしてその遅さが、教えのもう半分を授けたのです。使う余裕がなければ抽象化は無価値である、と。C++ は、Simula の贈り物を保ちつつ、そのコストを一切払わない試みです。（直接的で形成的な影響）

BCPL、そして C と UNIX をめぐるシステムプログラミングの文化。 BCPL は彼に対照的な痛み——生の速度はあるが、大きなものを何ひとつ組み立てる術がない——を与えました。そして C、Bell Labs における UNIX の言語は、C++ をその代わりにではなく上に築くための、高速でハードウェアに対応した土台を与えたのです。²⁵（直接的な影響）

Bell Labs。 C と UNIX を生んだその同じ組織が、Stroustrup に「C with Classes」を始めさせた分散システムの問題と、言語を正しく仕上げるのに何年も費やすことを許す研究文化を与えました。（形成的な影響）

彼が形づくった人々

世界のインフラは彼の言語の上で動いている。 オペレーティングシステム、ブラウザ、データベース、ゲームエンジン、コンパイラ、高頻度取引システム、火星探査車の飛行ソフトウェア——現代コンピューティングのパフォーマンスが要となる中核は、不釣り合いなほど C++ です。これほど荷重を支える仕事をしているエンジニアは、ごくわずかしかいません。

ゼロコスト抽象化の運動。 Stroustrup の原則は「ゼロコスト抽象化」と改名され、Rust の明示的な創設目標のひとつとなりました。Rust は RAII を（所有権と Drop として）、決定論的な破棄を、そして高水準の構文が最適な機械語へコンパイルされなければならないという規則を採用しています。D や Carbon のような言語も、同じ系譜から下っています。明快さの代価を払うべきではないという思想は、いまや主流であり、それは彼のものなのです。⁶

貫く一本の線

John Carmack は、内側のループに、物理が許すかぎり最小の仕事だけをさせたいと望みます——「光の速度は最悪だ」、機械は厳しい限界に支配され、無駄にした1サイクルはすべて選択である、と。Stroustrup は、そのループを読みやすく書くための道具を Carmack に手渡します。ゼロオーバーヘッドな抽象化とは、明快な版と最も金属に近い版が同じ機械語であるという約束であり、だからこそ選ばずに済むのです。Barbara Liskov が抽象化にその理論を与えた——データ抽象化、型がその利用者に負う契約、「ものがどう動くかではなく、何をするかに対してプログラムせよ」という Simula から CLU への系譜——のに対し、Stroustrup はその理論に、動かしても何のコストもかからない肉体を与えました。そして Alan Kay がオブジェクトを、メッセージをやり取りする小さなコンピュータ、遅延束縛された実行時の会話として思い描いたのに対し、Stroustrup は同じ語へ反対の道をたどりました。彼のオブジェクトはコンパイル時に解決され、剥き出しの機械語へと溶けていく。OOP は生きたメッセージバスではなく、ゼロオーバーヘッドの組織化の道具なのです。同じ語彙、二つの哲学——一方は柔軟性のために、もう一方は実行時の請求書のために最適化する。（シリーズの橋渡し）

ここから私が受け取るもの

私が手放さずにいる教訓は、「表現力か速度か」がほとんどの場合、まずい設計があなたに強いる誤った二者択一だ、ということです。「速くなければならないから」と醜い版を書いている自分に気づくとき、Stroustrup の原則が告発するのです。それはコンピューティングの法則ではない、それ自身が速いものへとコンパイルされる抽象化を見つけそこねた失敗なのだ、と。仕事とは、明快な版をあまりに巧みに設計し、機械がそこから最適なコードを生み出すようにすること——設計の段階で一度だけコストを払い、それを使うあらゆる行で二度と払わずに済ませることです。それは品質こそが唯一の変数であるという基準と同じものです。問いは決して「これを明快にする余裕があるか」ではなく、「なぜ私の抽象化は、明快さに何かしらのコストがかかるほど漏れているのか」なのです。

私がいま築いている世界——エージェント、ツールループ、AI システム——では、誘惑はゼロオーバーヘッドの正反対です。ラッパーの上にラッパーを積み、遅い経路を取り繕うためにモデル呼び出しを一回食い、便利な抽象化のひとつひとつに、誰も測らない遅延をそっと足させてしまう。Stroustrup の一手は、その便利なインターフェースが効率的なものへとコンパイルされることを要求する——きれいな API と速い経路が同じ経路であり、コストは、そこを流れるあらゆる呼び出しに請求されるのではなく、ハーネスの設計のうちに払われていることを要求するのです。その信念——センスとは技術的なシステムである、主張するだけの雰囲気ではなく、厳格な規則を突きつけられるものだという信念——こそ、遅すぎた1979年のシミュレータから、そうあってはならない2026年のエージェントハーネスへと貫く、一本の線なのです。

FAQ

Bjarne Stroustrup のエンジニアリング哲学とは何ですか？

Stroustrup の信念は、表現力のある高水準のコードと、ベアメタルのパフォーマンスのどちらかを、決して選ばされるべきではない、というものです。彼は ゼロオーバーヘッド原則 の上に C++ を築きました。言語機能は、使わないときには何のコストも生まず、使うときには、その作業のために手で書いたであろうものに劣らないコードへとコンパイルされなければならない、という原則です。¹ 彼はこれに、プログラマを信頼すること（C++ はあえてマルチパラダイムです）、ハードウェアへの直接対応、RAII による決定論的なリソース管理、そして言語を所有するのではなく開かれた ISO 標準として安定させることを組み合わせました。⁴⁶⁷

ゼロオーバーヘッド原則とは何ですか？

それは Stroustrup が二部構成で述べた規則です。「使わないものには（時間でも空間でも）代価を払わない。そしてさらに、使うものについては、手で書いてもこれ以上うまくは書けない」¹ 前半は、使われない機能は実行時にもメモリ上にも何のコストも課さない、という意味です。後半は、実際に使う機能は、有能なプログラマが手で書いたであろうものに少なくとも匹敵するコードを生み出す、という意味です。これは、すべての C++ 機能が通過しなければならない関門です。それを曲げる二つの機能——実行時型情報と例外——は、まさにたいていのコンパイラがオフにさせてくれる二つの機能なのです。⁶ この原則のおかげで、スマートポインタやイテレータのような C++ の抽象化は、生で手作業で磨いた版と同じ機械語へとコンパイルされ得るのです。

RAII とは何で、なぜ Stroustrup はそれを発明したのですか？

RAII——Resource Acquisition Is Initialization（リソース取得は初期化である）——は、Stroustrup が名づけた C++ のパターンで、リソースの寿命をスタック上のオブジェクトの寿命に結びつけます。リソースはオブジェクトのコンストラクタで取得し、デストラクタで解放するのです。⁷ C++ は、スタック上のオブジェクトのデストラクタが、そのスコープを離れた瞬間に——関数が通常どおり戻るのであれ、例外がスタックを巻き戻すのであれ——必ず走ることを保証します。だからメモリ、ファイル、ロック、ソケットといったリソースは、決定論的に、既知の瞬間に解放されます。ガベージコレクタもなく、手動で解放すべきものもありません。それは自動的で例外安全な後始末をゼロオーバーヘッドで与えてくれます。後に Rust が、所有権と Drop として、それをほぼそのまま採用しました。⁷

Stroustrup はなぜ C++ を作ったのですか、そしてそれはどこから来たのですか？

分散システムを扱うケンブリッジの博士論文を書いていたとき（1979年修了）、Stroustrup は Simula でシミュレータを作り、そのクラス抽象化を愛しましたが、規模が大きくなると遅すぎることに気づきました。彼はそれを BCPL で書き直しますが、BCPL は高速なものの、大きなものを築くには低水準すぎたのです。² どちらの取引も受け入れられるものではなかった。そこで Bell Labs で——UNIX カーネルをネットワーク越しに分析する問題に直面しながら——彼は C の速度を失うことなく、Simula の組織化する力を C に加えようと乗り出しました。彼はそれを 「C with Classes」（1979年）と呼びました。1983年、同僚の Rick Mascitti が C++ という名を提案します。⁴⁵ 2018年、全米技術アカデミーは彼に Charles Stark Draper 賞 を授与しました——工学におけるアメリカ最高の栄誉であり、しばしば工学のノーベル賞と呼ばれる50万ドルの賞で、C++ プログラミング言語の設計と実装の功績に対するものです。⁹

出典