「C++プログラミング言語の歴史と特徴」連載第10回目の今回も前回に引き続き次の公開論文を精読していきます。

第1回連載資料論文
　今回は、「2.2 Design Principles」節の中の、Low-Level programming support Rules(低レベルプログラミングに関するサポート規則）部分の意味を考えます。

　筆者は、この記事を書きながら、1994年に出版された「D&E」書籍の関連箇所を何度も何度も読み返しています。この連載で取り上げている論文は1999年に書かれていますから、「D&E」出版から5年ほど経過しています。ご承知のように、コンピュータの世界で5年前といえば、それはかなり昔のことであり、その技術や理論は（本質ではなく、表面上）現状にそぐわないことを意味します。「D&E」とこの論文の内容の間に決定的な相違や変化というものがあるのでしょうか？筆者は、そのような疑問を懐に入れながら、1994年書籍と1999年論文を比較しています。

　結論を急げば、2つの間に認識のずれはないといってよいでしょう。今回は、「Low-Level programming support Rules」表内の"No gratuitous incompatibility with C"規則に焦点を当て、1994年当時と1999年の主張内容を比較してみます。表内の残りの規則については、他の記事などで必要に応じて触れることにします。1994年当時は、Cとの互換性について次のようなことを強調しています。

・多数のCプログラマが存在する
・多数のCプログラムが使用されている
・C++は型の安全性とプログラム設計機能を重視する
・型の安全性とプログラム設計機能が保証されれば、これまでのC機能をサポートする

　ご覧のように、1994年当時は、Cプログラマへの配慮を強調しています。しかし、C遺産を継承するだけではC++の誕生と存在理由が問われますから、「型の安全性」と「プログラムの設計機能」という、Simulaから継承した機能も前面に出しています。そして、どちらを重視するかといえば、Simulaから継承した機能を優先することが明確にされています。

　これからプログラミング学習を始められようとしている方は、「型の安全性」や「プログラムの設計機能」といわれても、おそらく、ピンと来ないと思います。「型の安全性」の"型"とは、Typeであり、Classを意味します。そして、Classというのは、C++ユーザが独自に定義する"型"を示しています。このため、クラスは、ユーザ定義型（UDT）と呼ばれることがあります。int、double、あるいは、charなどのプログラミング言語が事前に用意している型は、"組み込み型"、"内蔵型"、"ビルトイン型"などと呼ばれます。ところで皆さん、型を独自に定義する、ということの意味がどういうことなのかお分かりになりますか。型を独自に定義するということは、少なくとも、コーディングをすることではありません。それではいったいなんでしょう。この当たりのことを少し突っ込んで考えてみましょう。

　"型を自分なりに定義する"ということは、簡単に言ってしまえば、自分の力でものを考えることです。たとえば、"豊田孝とはどのような人物だろう"と自問自答し、それを定義することです。そして、その定義内容を（コンピュータ用に）C++言語（や、他のオブジェクト指向プログラミング）で表現すれば、「豊田孝クラス」が出来上がるというわけです。

　"豊田孝とはどのような人物だろう"への回答は、人それぞれ異なります。その回答には、人それぞれの主観や感情も当然入ります。これは人間的で面白いところなのですが、"豊田孝とはどのような人物だろう"への回答をビジネスとして活用し、利益を生み出そうとすると、そこには戦略や戦術が必要になります。もちろん、作業効率も要求されます。"豊田孝とはどのような人物だろう"への回答を数年掛けて導き出すようではビジネスになりません。

　クラスを多用してソフトウェア開発を行っている現場では、UMLやオブジェクト指向開発プロセスなどの用語が常識になっています。それはなぜでしょうか。"豊田孝とはどのような人物だろう"への回答をビジネスとして利用しているからなのです。UMLやオブジェクト指向開発プロセスと聞くだけで気が重くなってしまう人がいますが、それはあくまでもビジネスの道具であり、クラスやソフトウェア開発の本質ではありません。この意味では、UMLなどは開発者ではなく、プロジェクトの発注者やソフトウェアユーザの表現道具といってよいでしょう（Excelを設計ツールに使用する現場事例）。このため、ソフトウェア開発者は、"必要になったら簡単に学習できるもの"と、気軽に考えておきましょう。道具の使い方を覚えるのではなく、(当たり前ですが）自分の力でものを考えることがはるかに大切です。

　私たちは型とクラスについてはある程度理解できるようになりました。それでは次に、「型の安全性」の"安全性"について考えてみましょう。前段で述べたように、型とはクラスです。クラスとは、私たちの想像力や思考の成果物をコンピュータ用に表現したものです。ここで注意していただきたいのは、クラスは、私たちが作り出す成果物、という事実です。そして、クラスを作り出す過程では、コンピュータの存在は一切意識されません。Cの世界は、あくまでも"まずコンピュータありき"ですが、C++が目指すのは、"まず人ありき"です。発想の転換が行われています。この点はきちんと覚えておきましょう。

　クラスは私たち人間が作り上げるものです。ところが皆さん、私たち人間は欲が深く、罪深い生き物です。ということは、どのようなクラスが作り上げられるかまったくが予測できません。クラスが好き勝手に作り上げられることを防止することは不可能です。しかし、"クラスは最終的にコンピュータ用に表現"されますから、"クラスは私たち人間が理解できると同時に、コンピュータも理解できなければならない"という制限が課されます。これはどういうことかといえば、"コンピュータが理解できるクラス"であることを保証する、つまり、人間の世界からコンピュータの世界へ、レベルを下げる作業が必要になる、ということです。この作業は誰が行うのでしょう。それは、コンパイラであり、リンカーです（JavaやC#の世界では、JVMやCLRと称される仮想マシンです）。型(クラス）の安全性を保証するとは、その型（人間の思考内容）が正常な計算式(コンピュータの認識可能内容）になることを確認する作業である、と考えてしまうとよいでしょう（表現には限界がある！）。

　たとえば、この春小学校に入学したばかりの子供たちにとっては、友達ができるかどうかが最大の関心事です。皆さんの近所の子が、"僕には友達がたくさんできたよ！"と言ったとしましょう。計算機から見ると、これはきわめて人間的な高度な表現です。計算機は、"たくさん"という表現を理解できません。それは、intであるかも分かりませんし、longであるかもしれません。この説明から、型の安全性を保証することの意味が、なんとなくお分かりいただけると思います。この場合の、「型の安全性」を保証するとは、コンパイラが"たくさん"という表現を検出し、"それは数式になりません！"という警告を出すことと考えてしまうとよいでしょう（あいまいさの訂正）。数式内で"たくさん"という表現を使用することはできますか？できませんね。

　私たちは、型、クラス、安全性などの概念を何とかわかるようになりました。今度は、「プログラムの設計機能」について考えてみましょう。クラスは私たち人間が作り出すものですが、だからといって、何もかもクラスとして定義してよいものでしょうか。あるいは、豊田孝とBjarn Stroustrup氏を無条件でクラスとして定義しても問題はないでしょうか。おそらく、問題はあるでしょう。C++仕様をさらに改善する場面で豊田孝クラスが必要になるとは到底考えられません。これは、場面場面で必要とされるクラスが異なるということを示しています。表現を変えれば、場面（問題）に応じて必要なクラスを作り出し、それらを適切に配置することがソフトウェア開発の重要な一部であることになります。考えもなしにクラスを作り出すのではなく、少し考えた（つまり、プログラムを設計した）上で、必要となるクラスの定義作業を開始する必要がある、というわけです。C++の「プログラムの設計機能」とは、このようにして考え出された複数のクラスとその関係をそのままソースコードとして表現できる抽象化機能といってよいでしょう。人間の思考内容（ソルーション）が無理なくソースコードになるわけです。

　さて、私たちは、1994年当時の「型の安全性」や「プログラムの設計機能」の意味を理解できるようになりました。当時の主張内容は、5年後の1999年に変更されているでしょうか。1999年論文には、次のような文が用意されています。

"It is also a problem that many programmers migrate from C to C++ without appreciating that radical improvements in code quality are only achieved by similarly radical changes to programming styles."

　この文は、"CからC++に移行するためには、プログラマはプログラミングスタイルの変化を理解する必要がある"と述べています。皆さんはすでに、この文の意味を実感を持って理解できる立場にあります。要は、CとC++間に存在する、発想上の違いを認識しなさい、と述べているのです。クラスという考え方を持たないCで豊田孝を定義することはかなり難しいといってよいでしょう。大企業の人事管理システムなどを想像してみてください。何人の人間がクラスとして定義されるでしょうか。想像できませんね。今回はこれ以上の説明は行いませんが、CからC++への歴史的な動きは、ソフトウェアの歴史にとってとても重要な意味を持っていることはご理解いただけると思います。C++の歴史とその特徴を学ぶことは、現代のソフトウェア開発の現状を理解することと同じなのです。

　"CとC++間に横たわる発想の相違"は大きいものです。2つの言語間の発想上の相違は、現在でも正確に理解されているわけではありません。Stroustrup氏は、クラスを次のように定義しています。

A class is the primary mechanism for representing concepts in C++.

　この文章は、"クラスというのは、C++で概念を表現するためのメカニズムである"と述べています。概念というのは、私たちの思考内容（ソルーション）を簡潔に整理（高度に抽象化）したものです。この一文からも分かるように、自分の力でものを考えることが何よりも大切です。概念は、確かに、「私たちの思考内容を簡潔に整理したもの」ですが、整理の過程では主観や感情も当然入り込みます。概念といってもその実体はかなりいい加減なものです。「私たちの思考内容を簡潔に整理する」過程は、「データを抽象化する」と呼ばれることもあります。

前へ | 次へ