2010-08-12

原文Bjarne Stroustrupへのインタビュー

新しいプログラミング雑誌、プログラミングの魔導書 vol.1では、C++の設計者にして最初の実装者であるBjarne Stroustrupへインタビューを行った。インタビューは、英語が使われた。その英語は、日本語に翻訳されて、雑誌に載せ、すでに発行されている。

しかし、翻訳というものを信用していない人もいるだろう。第一、ほかならぬ私自身でさえ、翻訳は嫌いなのだ。このたび、Bjarne Stroustrupが、自信のWebサイトで、原文を公開した。以下で落として読むことができる。

Stroustrup: Interviews

Interview by Royo Ezoe C++0x from now to the release of the Standard for a new Japanese mazagine called Programmers' Grimoire. April 2010.

インタビューの他でも、色々と興味深い問答があったのだが、すべてを載せることはできなかった。たとえば、Bjarne Stroustrupの原文では、以下のようなやり取りが付け加えられている。

(C++をどうやって教育すべきかという質問への追加、サブセット規格よりコーディング規約という返答に対して)

質問:

サブセット規格よりコーディング規約といいますが、テンプレートのないサブセット規格と、テンプレートの使用を禁止しているコーディング規約は、全く同じものではないでしょうか。技術上の理由は全くないにも関わらず、テンプレートやSTLやBoostの使用を禁止しているコーディング規約を強いられている人の話も聞きます。

Bjarne Stroustrupの返答:

コーディング規約は、明確に定義された、対象とするアプリケーションやその分野にあわせて設計されるべきである。さもなくば、問題を引き起こす。コーディング規約というものが、C++の経験が浅い者によって作られることも、実に多い。特に、ある団体の開発言語が、別言語からC++に移った場合によく起こることだ。わたしはかつて、まだC++でまともにプログラミングしたことのない者が、コーディング規約を書くという例をなんども見てきた。そういう場合、人は大抵、かつて自分が使っていた別言語にはない機能を禁止しようとしたり、別言語に存在する問題を防ぐためのルールを、C++にも当てはめようとする。これは、実にC++の利用に取って害悪である。たとえば、C畑からやってきた者は、関数のオーバーロードを極度に恐れるあまり、禁止する。その結果、彼らは問題の多いマクロを多用して、ジェネリックプログラミングのマネ事を行うのだ。実に非生産的である。他には、コンストラクターで、「複雑なこと」をするのを禁止したりする。その結果、不必要に問題の多い、二段階の初期化と、例外の誤用をするのだ。結果のC++コードは、まともなC++プログラマーによって書かれたようには見えん。C++でハンガリアン記法を使うというのも、明白に間違っている。

そもそも、良いコーディング規約というのは、禁止事項のリストではないのだ。よいコーディング規約は、言語の有効な使い方を示すべきなのだ。思うに、最良の方法とは、ライブラリを使うことによって、問題の多い非生産的な言語の使用を避けるべきなのだ。私が考案した、JSF++の基本的な考え方は、まず、言語をライブラリで、対象の分野に沿うように拡張しておいて(訳注:つまり、ライブラリの実装自体には制限を設けない)、それから(訳注:ライブラリを実装した後で)、ライブラリを効率的に使えるように、言語のサブセットを定義するのだ。このようにすれば、単に「言語のサブセット」より遥かに単純で安全な規約を作ることができる。例えば、JSF++は、ポインター変換や、ポインターと配列の関係、配列のオーバーフローの問題を、たったひとつのルールで解決している。インターフェースに配列を使うな(つまり、関数の実引数として)。データの集合を渡すには、何種類かの単純なコンテナを用意する。このコンテナは、安全ではない暗黙的な型変換を行わず、要素の数を把握している。MISRAのような、ポインターを安全に使えるようにする、などといったコーディング規約は、それ自体は何らプログラマの生産性に寄与しない、何十ものルールを付け加えなければならん。それでも、やはり問題は起こるのだ。このような問題は、愚直に言語を限定するというアプローチから生まれるのだろう。プログラマーに、言語自体の問題に対処させながら、しかも、その問題に対処するための、言語側で提供されている機能を使わせないというのだ。これをC++のサブセットに当てはめると、プログラマーは、高級なアブストラクション機能(クラスやテンプレート)を使えず、低級な言語機能(ポインターやキャスト)で対処しなければならないということになる。これは問題が多いし、非生産的である。

単なる言語のサブセットと、コーディング規約によって定められているサブセットの根本的な違いとは、完全なISO C++が、コーディング規約の実装者には提供されているということだ。よいコーディング規約とは、スーパーセットのサブセットであるべきだ。このスーパーセットというのは、C++と、対象の環境用のライブラリのことだ

テンプレートは、C++の型安全と効率のための根本的な機能だ。例えば、たったひとつの要素型しか使わない場合を除いて、コンテナが必要であるし、型安全で効率的なコンテナを実装するには、テンプレートが必要になる。組み込みの配列は、型安全なコンテナに比べたら、実に貧弱な選択肢だ。テンプレートの多くの機能(訳注:テンプレートの全機能ではない)をコーダーには禁止するコーディング規約はあったとしても、ライブラリを構築するためにも禁止しているような規約は、良い規約ではない。しかしだ。コーダーに、テンプレートの使用自体をまったく禁止するのがふさわしいような場面というのは、考えられん。とはいえ、すべてのコーディング規約は、テンプレートの利用を、その目的の分野にふさわしいように、制限をしてはいるだろう。

このほかは、雑誌で翻訳しているので、買って読んで欲しい。

3 comments:

Anonymous said...

テンプレート禁止は2度見たことあります。
1・実行ファイルの容量制限が厳しく、テンプレートを使っていられない

2・ハードの制約上例外が使えず、かつnewに失敗した場合にも適切に動き続けなければならない

双方、ハードの制約上仕方なくでした。そうでないのに禁止する(リーダーがテンプレートを理解していないからとか)のはアホだと思いますね。

Anonymous said...

> 2・ハードの制約上例外が使えず、

C++ 例外処理の実装にハードウェアの支援は必要ありません。この理由付けは
おそらく間違いでしょう。

> 1・実行ファイルの容量制限が厳しく、テンプレートを使っていられない

理想的なコンパイラ・ライブラリ実装であればテンプレートを使っても
必要なだけのコードしか生成されないはずなので、こちらも過去の話という
ことになっていくかと思います。

Anonymous said...

> C++ 例外処理の実装にハードウェアの支援は必要ありません。
> 理想的なコンパイラ・ライブラリ実装であれば

この指摘は正論ですがちょっと無茶だと思います。
問題点がC++のコンパイラ・ライブラリにあるとして、それを例えば修正して解決するのは難しいです。