現実のStroustrupインタビュー：C++は単にオブジェクト指向言語でない理由をC++の父は語る

The Design and Evolution of C++ (Addison Wesley, 1994)の中で、Bjarne Stroustrupは"プログラミング言語は実際には世界の実に小さな部分だ。だから、そんなに深刻に考えるべきでない。バランス感覚を保ち、最も大事なのはユーモア感覚を保ちなさい。主なプログラミング言語のうち、C++は豊富な駄洒落とユーモアの源だ。それは偶然ではない。"と論じた。ここ数ヶ月の間、StroustrupとComputerの偽インタビューがサイバースペースに巡回し続けている。私達はそのことを遺憾に思う一方で、標準C++と一般的なソフトウェア開発についてC++の父にその考察を聞くまたとない好機を与える。私達は彼の変わらぬバランス感覚とユーモア感覚を証明も出来る。すなわち、彼自身で書いたなら、その架空インタビューはもっと楽しいパロディになっていたであろうと、彼は主張する。
-Scott Hamilton, Computer

標準C++
Computer: 1997年11月、ISOは標準C++を承認し、貴方はThe C++ Programming Language (Addison Wesley, 1997)の第3版を刊行した。ここ数年に渡って、C++はどのように進化し、C++コミュニティにとってISO標準は何を意味するのか？

Stroustrup: C++の完全な事細かな安定した定義をやっと持つことは大きい。これは無数の直接及び間接的な面でC++コミュニティへの大きな助けになる。明らかにコンパイラ提供者が標準委員会に追いつくことから実装品質の問題へと関心を移し始めているので、私達はより良い実装を得るだろう。これは既に起こっている。

標準適合実装は、大きな共通プラットフォームを与えることによって、ツール及びライブラリ提供者にとって恩恵となるだろう。

標準はプログラマに新しいテクニックを使って、より冒険的な機会を与える。製品コードの中で非現実的に使用されたプログラミングスタイルは実際的な記述となる。従って、より柔軟、一般的、速い、保守性の高いコードを書くことが出来る。

当然、私達は冷静さを保ち、"高等"テクニックに浮かれてはならない。尚も神技は無いし、最良のコードは堅実な設計に最も直接的にマッチするコードである。しかし、今はどのテクニックが特定の人々、組織、プロジェクトに相応しいか試し見る時だ。C++プログラミング言語の大部分は、これらのテクニックとトレードオフに心血を注いでいる。

この進化を実行可能にしている最も明らかな面は、言語の"新しい"主要な機能、すなわちテンプレート、例外、ランタイム型情報、名前空間と新標準ライブラリだ。言語詳細のマイナーな改善も重要だ。私達は今より数年の間に機能の大部分を得るが、ポータビリティと製品品質を必要とした処では、それらの機能に依存出来ない。これは、ライブラリとアプリケーションの設計と実装に対して次善のアプローチを強いる。しかし、すぐに（今年中）主要な実装すべてが標準C++の堅実なサポートをするだろう。

プログラムとプログラミングテクニックの観点から、C++への最も重要な変更は、静的立証可能な型安全に対する変わらぬ重視と、テンプレートの増々な柔軟性だ。柔軟なテンプレートは、簡潔性と効率性の観点から型安全の重視を成功させるために必須である。

新しいテクニックの実行可能性
Computer: 貴方は"経験豊富なC++プログラマが長年よく見過ごすことは、新しいフィーチャーそれ自体の導入ではなく、むしろ、基本的な新しいプログラミングテクニックを実行可能にするフィーチャー間の関係における変更である。"と言っている。これがどのように標準C++に適応されるか例を与えていただけるか？

Stroustrup: オーバーロードとテンプレートのルールを、それらが簡潔で効率良い型安全なコンテナに対する鍵の一つであることを知らないで、学習するのは簡単だ。コンテナの最大限の活用に共通する基本的なアルゴリズムの中を調べる時のみ、この関係は明確になる。以下のFigure 1aのプログラム断片を考えよう。count()の最初の呼出しは、整数のベクタにおける値7の出現回数を数える。2番目のcount()の呼出しは、文字列のリストにおける値"seven"の出現回数を数える。

// Figure 1a:
 
void f(vector<int>& vi, list<string>& ls)
{
    int n1 = count(vi.begin(),vi.end(),7);
    int n2 = count(ls.begin(),ls.end(),"seven");
    // ...
}
 
// Figure 1b:
 
template<class Iter, class T>
int count(Iter first, Iter last, T value)
{
    int c = 0;
    while (first!=last) {
        if (*first == value) c++;
        ++first;
    }
    return c;
}
 
フィーチャー間の関係の変更は、基本的な新しいプログラミングテクニックを実行可能に出来る。すなわち、(a) 文字列のリストにおける値"seven"の出現回数と同様に、整数のベクタにおける値7の出現回数を数えるcountアルゴリズムは、(b) テンプレートを使って両方の呼出しを処理する単一の関数になる。

オーバーロードを許すすべての言語で、これを行う方法はいろいろある。テンプレートがあれば、Figure 1bで見たように、両方の呼出しを処理する単一の関数を書くことが出来る。このテンプレートは二つの呼出しのために最適なコードへと展開する。このcount()は大雑把に標準ライブラリのcount()に等価で、ユーザはそれを書く必要は無い。count()関数自体はオーバーロードに頼っている。つまり、明らかに等価オペレータ==は整数と文字列のためオーバーロードされている（明白な理由があって）。更に、*と++が"デリファレンス"と"次の要素に言及"の意味を持って、ベクタとリストのためにオーバーロードされている。すなわち、*と++はポインターとしての意味合いを与えられる。

count()のこの定義は、C++標準ライブラリのコンテナとアルゴリズム部で使用される重要なテクニックのいくつかを例証する。これらのテクニックは便利であり、言語の基礎的なルールのみによって、簡単に発見されていない。

Figure 2aに見るように、もう少し高度なバリエーションのcount()の例を考えよう。値の出現回数を数える代わりに、count_if()は前提を満足する要素を数える。例えば、Figure 2bで示すように、7より以下の値を持つ要素の数を数えることが出来る。

// Figure 2a:
 
template<class Iter, class Predicate>
int count_if(Iter first, Iter last, Predicate pred)
{
    int c = 0;
    while (first!=last) {
        if (pred(*first)) c++;
        ++first;
    }
    return c;
}
 
// Figure 2b:
 
bool less_than_7(int i) { return i<7; }
 
void f2(vector<int>& vi, list<int>& li)
{
    int n1 = count_if(vi.begin(),vi.end(),less_than_7);
    int n2 = count_if(li.begin(),li.end(),less_than_7);
    // ...
}
 
countの高度バリエーションの例は、(a) 前提に合致する要素の数を数え、例えば(b) 7より以下の値を持つ要素を数える。

任意の型の任意の値の比較を処理するために、このテクニックを一般化することは、関数オブジェクトを定義する必要がある。すなわち、Figure 3aで示すように、関数のように呼出し可能なオブジェクトのクラスだ。Figure 3bにある通り、比較したい値への参照をコンストラクタは格納する。適応オペレータ（operator()）は比較を行う。言い換えれば、整数7より以下の値を持つvi内の要素を数え、文字列"seven"より小さい値を持つls内の要素を数える。

// Figure 3a:
 
template <class T> class Less_than {
    const T v;
public:
    Less_than(const T& vv) :v(vv) {} // constructor
    bool operator()(const T& e) { return e<v; }
};
 
// Figure 3b:
 
void f3(vector<int>& vi, list<string>& ls)
{
    int n1 = count_if(vi.begin(),vi.end(),
        Less_than<int>(7));
    int n2 = count_if(ls.begin(),ls.end(),
        Less_than<string>("seven"));
    // ...
}
 
任意の型の任意の値の比較を処理するためには、(a) 関数のように呼出し可能なオブジェクト（関数オブジェクト）のクラスを定義し、そのクラスは(b) 比較したい値への参照を格納するコンストラクタを持つ。

生成されるコードは非常に効率的で、特別に関数呼出し又は比較を実装する割合い遅い、次の要素を順次読み込むオペレーションを使用しないことは明記するに値する。

残念ながら、このコードはC++プログラマでない人や、テンプレートとオーバーロード（勿論、ここで例を示す目的の一部分である）を使う最新のテクニックを消化仕切れていないC++プログラマにとっても異様に映る。しかし、根底にあるのは、これらのテクニックが効率良い、型安全で、総称的なコードを書くのを可能にすることだ。関数言語に馴染んでいる人は、これらのテクニックが関数言語が先駆したテクニックに似ていることに気付くだろう。

言語のフィーチャーは基本的に単独では面倒であり、良いシステム構築の邪魔になり得る。プログラミングテクニックの背景の中にあってのみ、言語のフィーチャーは生きるのだ。

標準ライブラリ
Computer: 標準ライブラリはどのように定義されたのか、またC++コミュニティにおいては何のインパクトを持つか？

Stroustrup: 標準ライブラリの最も斬新で面白い部分は、コンテナとアルゴリズムのための一般的な拡張可能なフレームワークだ。よくSTLと呼ばれ、主にAlex Stepanov（当時はHewlett-Packard研究所にいて、今はSilicon Graphicsにいる）の功績である。

Alexは、妥協せず一般的で効率的な基本アルゴリズム（例えばデータ構造の中に要素を探す、コンテナをソートする、又はデータ構造の中の値の出現回数を数える）を提供することに従事した。そのようなアルゴリズムはコンピューティングにとって非常に根本的だ。

Alexは様々な言語に取組み、長年に渡って多くの協力者、注目すべきはDavid Musser（Rensselaer Polytechnic Institute）、Meng Lee（HP Labs）、Andrew Koenig（AT&T Labs）を持った。私のSTLへの寄与は小さいが、重要だと考えている。すなわち、mem_fun()と呼ばれるアダプターを設計した。それは多態性オブジェクトのコンテナのために標準アルゴリズムを利用可能にし、従って、オブジェクト指向プログラミングテクニックを手際よく、標準ライブラリの総称プログラミングフレームワークの中へと試みることになる。

やや私が驚いたことは、私が長年開発して来たC++のための標準コンテナの良い一揃いのための基準の傾向に合致したことだ。一年くらいのSTLの議論と洗練の後、ISO C++委員会はSTLを標準C++ライブラリの重要な部分として承認した。私の基準は、

・簡潔な基礎的オペレーション（例えば、配列指標付けは関数呼出しのコストを招くべきでない）の妥協のない効率性
・型安全性（コンテナからのオブジェクトは、明示的又は暗黙的な型キャスト無しで使用出来るべき）
・一般性（ライブラリは、ベクタ、リスト、マップのようないろいろなコンテナを提供すべき）
・拡張性（標準ライブラリが私が必要とする或コンテナを与えないなら、私がそれを作り、標準コンテナであるように使用出来るべき）

を含んだ。マイナーな修正と追加のみでSTLを採用することにより、委員会による恐ろしい設計を避けた。

明らかに、パートタイムのボランティアのグループ（C++標準委員会）が、プログラマが便利だと思うすべての機能を与えることは出来ない。従って、主要な議論は標準ライブラリに何を含め、何を産業と個人に任せるべきかだった。

私達は、何を含めるべきかの指針として、"別々に開発されたライブラリ間のコミュニケーションに必要となるもの"を使うと決めた。従って、I/O、文字列、コンテナは主要な焦点になった。私達はC標準ライブラリと歴史的理由のため数値計算用の或機能を含めたが、日付と通貨、正規表現マッチング、グラフィックのような潜在的に便利な機能を除外した。幸いにも、これらの機能は商用又はパブリックドメインで入手可能である。

標準ライブラリは車輪の再発明をしなければならないことからプログラマを救う。特に標準コンテナは初心者とエキスパートの両方に高レベルでプログラムすることを可能にする。Figure 4の簡単なプログラムを考えよう。これは実に簡単な仕事を実行する。マクロ無し、明示的なメモリ管理又は他の低レベル言語機能無し、リソース制限無しで、仕事している。特に、おどけ者が30,000文字の"ファーストネーム"をプログラムに与えても、プログラムはオーバーフロー又はその他エラー無しで正確に印字を返すだろう。

// Figure 4:
 
int main()
{
    cout << "Please enter your first name:\n";
    string name;
    cin >> name; // read into name cout
    << "Hello" << name << "!\n";
}
 
標準ライブラリフィーチャーを使って簡単にその仕事をする、簡単な"Hello"プログラム。

標準ライブラリの使用は、C++の教え方を変革出来、また変革するに違いない。高レベル言語としてのC++を学ぶことは今や可能である。必要とされる時及び低レベル機能を議論するに相応しい状況を与える程に言語を十分にマスターした後のみ、学生は低レベルプログラミングの機能を扱う。従って、標準ライブラリはツールとしてのみならず、教師としてのサービスを行う。

複雑さ、C++、オブジェクト指向プログラミング
Computer: "C++プログラミング言語"の中で、貴方は"通常の実務プログラマが、あらゆる種類と規模のプロジェクトにおいて生産性、保守性、柔軟性、品質の著しい改善を達成して来ている。"と言っている。それでも、C++、一般的にはオブジェクト指向は過度に複雑で、大きなシステムでは矯正保守と保守問題を引き起こすという主張の批判がある。これらの批判は、C++での大きなシステムの開発者としての貴方自身の経験とどのように調和するのか？

Stroustrup: 私個人の経験では、オブジェクト指向設計とオブジェクト指向プログラミングは、手続きアプローチよりも良いコードへ導く。つまり、著しいパフォーマンスのオーバーヘッドを強いること無しに、より柔軟で拡張性があり保守可能なコードだ。私が希望する程の確固たる証拠は無い（個人的な考察に反して）が、AT&T内やその他での多くの研究がこの意見を支持する。

二つの要因が問題を混沌とさせる。すなわち、何が"オブジェクト指向"なのか一般的な一致が無く、議論は滅多に経験を十分に説明しない。"オブジェクト指向でトラブル"の大部分が、部分的理解（更に独善的で、典型的にオブジェクト指向コードはこう見えるに違いないという、閉ざされた考えを持ち）のまま野心的なプロジェクトに接触する、オブジェクト指向経験の余り無い人々に由来する。

それでは、オブジェクト指向とは何なのか？ 確かに全ての良いコードがオブジェクト指向とは限らないし、全てのオブジェクト指向プログラムが良いコードとは限らない。もしそうなら、"オブジェクト指向"が単に"良い"の同意語となるだろうし、現実的な決断を下す必要がある時、そのコンセプトは殆ど役に立たない愚純な流行語となるであろう。私は、オブジェクト指向プログラミングを、クラス階層及び仮想関数（或言語ではメソッドと呼ばれる）を十分に使用することと同じだとする傾向がある。クラス階層と仮想関数が（付随する設計哲学と共に）Simulaをその当時の他の言語との違いを示すものだったので、この定義は歴史的に明白だ。もっとはっきり言えば、Smalltalkが最も強調したのはSimulaの遺産である。

クラス階層と仮想関数の使用に基づいてオブジェクト指向を定義することは、オブジェクト指向が多分上手くいく処に関して或指針を与える意味において、現実的でもある。人は階層的順序を持つコンセプト、実装を共有出来るコンセプトの変形、正確に同じ型である必要なしに共通のインターフェイスを通して操作が可能なオブジェクトを求めている。これは、少数の例と少しの経験があれば、設計への強力なアプローチの基礎に成り得る。

しかし、全てのコンセプトが自然的且つ有益に階層へフイットするとは限らない。コンセプト間の全ての関係が階層的とは限らない。全ての問題が一義的にオブジェクトに的を絞ったアプローチでベストとは限らない。例えば、幾つかの問題は実際には主としてアルゴリズム的である。従って、一般目的のプログラミング言語は、多くの考え方と多くのプログラミングスタイルをサポートしなければならない。この多彩さは、解決されるべき問題の多様性とそれらを解く方法の多さの結果である。C++は様々なプログラミングスタイルをサポートし、従って、オブジェクト指向と言うよりはマルチパラダイム言語（人が意匠を凝らしたラベルを必要とするならば）と呼ばれる方がもっと適当だ。

"優秀さ"（理解し易い、柔軟、効率）のための基準の大部分に合致する設計の例は、再帰下降パーサーだ。それは伝統的な手続きコードである。別の例がSTLで、STLは伝統的な手続きコードとパラメトリック多態性の両方に極度に依存するコンテナとアルゴリズムの総称ライブラリだ。

私はたった一つのプログラミングパラダイムしかサポートしない言語が窮屈であるのを知っている。それらは、プログラマを拘束することより、又は言語からアプリケーションの中へ複雑性を追いやることにより簡明性を得るのだ。これは特定目的の言語としては相応しいが、一般目的の言語としては相応しくない。

私はよく、C++をシステムプログラミングも含む一般目的言語として特徴付けて来た。データ抽象化、オブジェクト指向プログラミング、総称プログラミングをサポートする"ベターC"としてC++を考えてみよう。当然、プログラミングへのアプローチが一つより多いサポートは一つのみのアプローチよりも複雑になる。私はこの考え方（つまり、ドメインに対応してベストな設計やプログラミングアプローチがあるということ）が或人々の感情を害していることに気づいた。明らかに私は、誰にとってもどんな問題にとっても正しい一つの方法があるという考えを拒絶している。世界は基本的に簡単であると感情的に信じたい人々は、私がプログラミング言語のためよかれと考えていること以上に怒りを持って反発する。何と言っても、プログラミング言語は、私達がシステム構築するための多くの中の一つのツールに過ぎない。

その二つの考えを解消する理想的な方法は、簡単な原理（そこから、すべての良いプログラミングスタイルを効率良くサポートする）の一式を与える言語を持つことであろう。これは繰返しトライされて来たが、私の考えでは達成されていない。

JAVAとC++
Computer: 平易さに対する同じ議論がもしかしてJavaにも拡張されるであろうが、それはSunが言う700,000人のJavaプログラマ（150万人のC++プログラマと比べて）を説明しているかも知れない。たとえC++がCとの互換性の必要が無くても、Javaは貴方が設計したであろう言語ではないと、貴方は主張している。何百回とこの質問を受けた後に、他に何か言わなければならないことがあるか？

Stroustrup: この頃、私はJavaについていつも聞かれるが、返答が非常に難しい。私が何かネガティブなことを言えば、不愉快に聞こえる。私が何かポジティブなことを言えば、Javaを囲む商業的誇大宣伝と、一部Javaコミュニティから発せられる不幸な反C++宣伝活動に私が餌を与える。

商業的競争の状況ではなく、設計基準に従って2つの言語を考えるよう、私は人々に奨励する。"The Design and Evolution of C++"でC++の設計基準を詳細に書いた。Javaはそれらの基準に合致することすら始めていない。プログラマがJavaを他のプログラミング言語の一つとして考えている間は、それで結構だ。C++はJavaの設計目標に対しては完璧でもない。しかし、Javaが唯一のプログラミング言語として推進される時、その欠点と限界は深刻になる。

その基準がC++開発に適用され、重要な違いを導く例がある。Javaと違って、C++は、
・他の言語で書かれた部分から効果的にプログラムを構成する能力
・様々な設計とプログラミングスタイル
・ビルトイン型に十分近いユーザー定義型
・ビルトイン型とユーザー定義型の統一的取扱い
・ランタイムのオーバーヘッドが無い、総称的コンテナ（例えば、STL）を使用する能力

をサポートする。私は、プログラマがエレガント且つ効率的なコードを書けるようにC++を設計した。多くのアプリケーションに対して、エレガンスと効率性に妥協したくない時、C++は尚もベストな選択である。

"プログラマ"をどのように数えるのか不思議に思う。学生がプログラマか？ 出荷されたコンパイラがプログラマとして数えられるのか？ 私はC++に対して引用される数を知っている。それは控えめで筋が通っている。実質金額で売られたC++実装の良い近似値だ。私はSunのJava数が確かなのか疑問に思う。次いでながら、私が見つけた幾つかの確かな数字（例えば、コンパイラの売上数、本の売上数、C++コースの出席者数のような）に基づけば、C++ユーザーの総数は年に10から20%増大していると私は見積もる。

いやそうではない。私はJavaファンではない。私は誇大宣伝が嫌い、非プログラマへのプログラミングツールのマーケティングが嫌い、プロプライエタリ言語が嫌いなのだ。私はプログラミング言語の多くは好きだ。テクニカルな面においては、Javaは決して私に"おお、素晴らしい！"という（他の多くの言語で経験した）反応を与えなかった。私が限界だと考えている形で大衆向け言語フィーチャーを与えている。

JavaはC++から随分と借用しているが、よく言われている程ではないし、人が望んでいた程には趣きと共感を持っていない。主要な約束を果たすためには、Javaは成長しなければならない。この進化は、C++より簡単であるというJavaの主張を譲歩するかも知れない。だが、私の考えでは、その試みはJavaを今日よりも良い言語にするだろうと思う。今の所、Javaは言語フィーチャーと"標準"ライブラリをかなりなペースで蓄積しているようだ。テンプレートのJavaバージョンが何に見えるのか楽しみだ。私が知っている限りでは、Sunは一ダースかそこらの方言を喜んでいない。

Javaとそのコミュニティが成熟するに連れて、出来れば良識的な共存哲学を採るだろう。このことは、Javaをプロフェッショナルなプログラマのツール箱の中の多くのうちの一言語として、その地位を占めることを可能にする。

ツール
Computer: 過去数年に渡って、システムは何の方法に変わったのか、そしてC++界と一般的にシステム設計において、何がまだする必要があるのか？ この時点でC++は比較的成熟しているとして、入手可能なC++開発ツールをどのように評価し、何がまだ改善する必要があるのか？

Stroustrup: 第一に、私は、コンパイラ、デバッガ、プロファイラ、データベースインターフェイス、GUIビルダー、CADツール等のような基礎的ツールがISO標準を十分にサポートするのを見たい。例えば、データベースクエリの結果をSTLコンテナ又は適切に型付けられたistreamとして見たい。ツールベンダーは良いスタートをしたが、コンパイラと他のコードアナライザに依存するツール内でするべき作業が多くある。

基礎的ツールの私のリストは、何が変わったのかの質問に対する部分的回答だ。過去数年に渡って、非常に多くのプログラマが、システム機能を持つコードをインターフェイスするための精巧なツールに頼るようになった。これらのツールは、プログラマから面倒でエラーしやすい作業を取り除くために不可欠であるが、プログラマ（と、彼等の雇い主）がツール提供者の囚われの身になるリスクに向かって来る。しばしば、これらのツールは伝統的なプログラミング言語よりも遥かに複雑で、ほぼ標準が無い。

ツールとライブラリには非プロプライエタリ標準をお薦めする。短期間、例えば10年経てば、多くのそのような標準が公式なISO又はIEEE標準よりも、産業界の標準になるであろうが、ソフトウェア産業の健全のためには、主要なインターフェイスが上手に記述され、公に入手可能であることが不可欠だ。COMやCORBAのようなシステムレベルの重要性が大きくなれば、それらへのC++バインディングがクリアで、よく文書化されていて、使用が簡単であることは特に重要である。残念ながら、そのような"標準化作業"（誰にとっても有益だ）は、短期間の競争に優位を与えないので、放ったらかしにされている。

入手可能なC++ツールを明確に"格付け"したくない。それらがかってよりも良くなっており、他の言語のどのツールよりも大抵同等又は良い。だが、一プログラマとして私は当然ますます品質の良いツールを切望する。個人的にはC++ソースコード解析のより良いツールを楽しみにしている。C++実装ベンダーが、斬新さを重視するよりもコンパイラの品質とパフォーマンスの改善に投資することも希望する。コンパイラの本当の改善は、完全なC++実装の新しいリリースに費やされるものに比べるとどちらかと言えば安価だ。しかし、多くのユーザーが適合したテストとベンチマークを要求しないと、ベンダーは宣伝的によく見えるものにしか投資しないことを私は危惧する。

将来
Computer: 私は貴方がC++標準化プロセスに深く関わって来たことを知っているが、現在他の何のプロジェクトに関わっていて、どのようにC++発展のための作業を続けるつもりか？

Stroustrup: 私は非常に大きなプロジェクトを成功裡に完遂させた。ISO C++標準化は終わった。"C++プログラミング言語"の第3版は、標準C++が提供しなければならないこと、どのようにそれを上手く使うか、真剣なプログラマに知らせるためにある。"The Design and Evolution of C++"はC++を形作った設計指針を文書化している。やったことはもっとあるが、それらは言語設計者とは関係がない。今や、可能な変更に焦点を当てるよりもコードを書くことでC++の柔軟性とパワーを楽しむ時だ。

それとは別に、幾つかの事（幾らかの新しい言語と大きなビジネスでソフトウェアはどのように使用されるかについて）を学ぶ機会を持ち、分散コンピューティングでの実験を計画している。