C++によるオブジェクト指向開発のメリット：Symbian OS開発の勘所（3）（1/3 ページ）

Symbian OSといえばC++だが、C++であるが故に敬遠する開発者も多い。そこで、なぜC++なのかを解説する

[大久保 潤 管理工学研究所，＠IT MONOist]

　前回でOSのデザインと基本的なメカニズムについての説明が一通り済んだので、今回からはSymbian OS上でのシステム開発にフォーカスして、より詳しく解説していきます。ということで、まずはSymbian OS上のシステム開発で避けて通れない「C++」の話をしようと思います。

　Symbian OSのAPIはすべてC++のクラスベースで提供されていますし、OS自身も95％以上がC++で書かれています。そのようなわけで、C++の特徴や特性を理解しないままSymbian OSでプログラムを書くのは、開発をとても難しい（もしくはとても不幸な）ものにします。そこで今回は、C++の特徴と、それをSymbian OSがどのように使っているかを解説します。また、Symbian OSがC++を使っているというだけで避ける向きもあるようなので、言語自体に対する誤解の解消ももくろんでみます。

なぜC++なのか

　最近は、Javaや.NETなどのガベージコレクション（GC）付きオブジェクト指向言語（OOPL）と、昔ながらのC言語の間に挟まれて振るわないように思われがちなC++ですが、そんなことはありません。ある程度以上の規模のシステムを、性能やリアルタイム性のことを考えながら書ける言語は非常に限られています。

　タスクのスケジューリングを考えるとき、最悪性能などの実行性能が分かっていることがとても重要です。さもないとタスクの優先度設計を適切に行うことができません。そのため、プログラムには「決定性」つまり「同じプログラム上のパスに対しては同じ実行コストが保証される」という性質が要求されます。しかし、GC付きのオブジェクト指向言語ではこれを保証できません。「メモリがいつ解放されるか分からない」という性質は、非決定性の最たるものです。Non-Deterministicな言語の上でリアルタイム性を保証するプログラムを書くのは、大変というより無謀の範疇に属することでしょう（注）。

※注：

「GCを呼んで明示的にメモリを解放すればいいじゃないか」というナイーブな意見を聞いたこともありますが、しかしそのGC呼び出しの単価がいくらに付くのかというのはやはり不明です。あらかじめメモリを取っておくという対応は環境によらず一般的ですが、すると2種類のメモリプールを意識せざるを得ないことになります。

　しかしいくら決定性が必要だとしても、構造体をむき出しで使うCにはいまさら戻れません。1人でプログラムを書くならいざ知らず（注）、構造体の中のフィールドを勝手に触るプログラマーがプロジェクトの中に1人いるだけで、どんなに立派なデザインもすべて台無しです。

※注：

筆者としては、たとえ1人のプロジェクトだとしてもCを使う気になれません。classも仮想関数もない世界だなんて！

誰だ、ここに-1を入れたやつは！ 仕様書では0から1000の範囲の値が入ることになっているのに

　1週間を費やしてようやく見つけた不具合の原因が、あるプログラマーの“ちょっとしたアイデア”の結果だったりすると目も当てられません。彼女／彼の言によれば「そのフィールドが無効であることを明示的に示したかった」からなのだそうです。

　このように、構造体のフィールドに割り当てられた仕様の解釈について、プログラマーが想像力を発揮することが、デザイナーやPMにとっての悪夢の源になる可能性が大いにあります。デザインと実際のコードとのギャップが激しいため、プログラマの自由裁量の範囲が広くならざるを得ない言語、それがCだといえるでしょう。そんな言語を使って、一度ROM化を行うと容易に更新が利かないソフトウェア、しかも大規模かつ複雑なものを書くのは筋の良い話ではありません。

図1　言語マップ

　獲得した機能という観点から、C++とほかの言語の関係を整理したのが図1です。アセンブラとCの違いは、構造化サポートの有無。CとC++の違いは、オブジェクト指向サポートの有無。C++とJavaや.NETの違いは、GC機能の有無と読んでください。こうすると、Symbian OSがC++を全面的に採用している理由がはっきりします。ROMベースの携帯電話、スマートホン向けの環境としてはCでは非力過ぎ、VMをベースとしたOOPLではtoo muchなのです。