連載
» 2007年04月24日 00時00分 公開

Symbian OS開発の勘所(4):C++のメモリリークを防ぐフレームワーク (1/3)

C++のデメリットといわれるメモリリーク。これを克服するために、Symbian OSではメモリを管理する独自フレームワークが導入されている

[大久保 潤 管理工学研究所,@IT MONOist]

 前回は携帯電話・スマートフォン開発でC++を使うメリットと、Symbian OSにおける使いこなしのためのアプローチ、命名規則(ネーミングコンベンション)を説明しました。今回はこれに続き、Symbian OSの三大特徴の1つ、例外処理にも耐えるメモリ管理フレームワーク(正しくはリソース管理フレームワーク)の解説を行います。

Symbian OSとフレームワーク

 いよいよフレームワークという言葉が登場してきました。Symbian OSを理解するうえで欠かせない概念であるフレームワーク、これはソフトウェア開発における一般概念で、


汎用的に適用できるプログラムの設計モデルや典型的な処理パターン


と定義されます。何だか抽象的な文言に見えますが、分かってみれば実にusefulな定義であり概念なので、ちょっと寄り道して解説をしたいと思います。

 OSの構造と基本APIが定まり、言語の使い方について合意が取れたとしても、実際に書かれるプログラムとの間には、まだ大きなギャップがあります。このギャップの解消こそ、生産性や品質の向上に対する鍵であることはすでに常識です(よね?)。これに対する古典的アプローチとして「ライブラリによる部品化の促進」がありますが、コード量(LOC)の増加やAPIの複雑化につれて以下のような問題が現れてきます。

1.API群の発行順序などが呼び出し側任せになってしまう
処理パターンに関する抽象化ができない

2.機能が増えてくると、どの手続きを呼べばよいのかが分からなくなる
量を整理する概念がない。膨大なドキュメントを丸覚えしたくない

 特に1.はかなり深刻です。処理パターン部分を呼び出し側でコーディングする必要があるということは、

  • 「コピーして修正」アプローチを取ることになり、修正漏れや仕様変更漏れなどが容易に起こせる
  • あちこちで処理パターンに関する「車輪の再発明」が起きる

といった事態が発生することを意味します。これは生産性や品質に対する重大な脅威です。ライブラリは確かにプログラムと実行基盤(OSの構造と基本APIと言語の使い方)のギャップを埋めることに一定の成果を上げてきました。しかし要求される機能が高度化し続けるなか、ライブラリアプローチだけでは足りなくなってきているのが組み込みプログラムの現状です。

 もちろんこのようなことを自信を持って断言できるのは、PCやサーバ、ワークステーション、そのほかさまざまなコンピューティング環境において、これが「いつかきた道」だからです。

フレームワークのメリット

 そこでフレームワークです。手続き的な部分だけではなく「汎用的に適用できるプログラムの設計モデルや典型的な処理パターン」を集約し提供するアプローチは、プログラムの記述量を大幅に削減します。生産性や品質はコード量(LOC)に強い相関を持っており、LOCが減るということはこれらの改善に大いに寄与します。

 手続き型言語全盛期には、フレームワークといえば関数ポインタを介したコールバックとイコールのような印象がありましたが、最近はオブジェクト指向言語の活用により、対象領域(ドメイン)に適した自然な記述ができるようになっています。

 Symbian OSでは至るところにこれらフレームワークが用意されています。その結果アプリケーション開発者の視点からSymbian OSの環境を見ると、図1のように見えるはずです。

Symbian OSにおけるフレームワークの位置付け 図1 Symbian OSにおけるフレームワークの位置付け

 フレームワークという言葉に対して、覚えるのが面倒だとか、いまのままの開発スタイルで十分だとか、設計の自由度が下がるのがいやだとか、ネガティブな反応を目の当たりにすることがままあります。別に「自由は屈従である」とまでいうつもりはありませんが、車輪の再発明をやめ、フレームワークに従うところは従っておくと、無駄な仕事が減り、別のことに資源を投入するという選択ができるようになります。簡単にいうと「フレームワークを使うとトータルでの自由度が上がる」のです。

 ちなみにWindows環境では、フレームワークへの取り組みがずいぶん前から真剣に行われています。Win32 APIをラッピングするアドオンのフレームワークであるMFC(Microsoft Foundation Class)を経て、現在では.NET Frameworkも3.0まで進化しました。筆者もWindows向けにごりごりプログラムを書いていたときには、MFCにずいぶんとお世話になりました。あの膨大なWin32 APIを生で使うための努力をするくらいなら、別のことに時間を使う方が気が効いている。そう思った人がマイクロソフトにいたわけで、まことに慶賀の至りでした。

 なおマイクロソフトにおけるフレームワークという言葉の使い方は、Symbian OSのそれと微妙に違いがあるので注意が必要です。.NET Frameworkというと、美しく統合された一枚板(monolithic)なフレームワークがあるような印象を受けますが、その中には対象領域(ドメイン)ごとのフレームワーク群がいくつも存在しています。だから.NET Framework といういい方はマーケティング上の要請もあってのことなのだろうと思います。このあたりはテクノロジ要素をむき出しにしているJavaと対照的です。ではSymbian OSはどうなのか、というとどちらかというとJavaに近い提示の仕方をしているようです。

Symbian OSの構造に関する誤解

 MFCというキーワードが出たついでに、Symbian OSに関する誤解を1つ払しょくしておきます。

これはSymbian OSの構造ではない! 図2 これはSymbian OSの構造ではない!

 OS、C++、フレームワークという三題噺に関してMFCという先例があるため、Symbian OSも図2のような構造をしているという誤解を耳にすることがあります。が、Symbian OSはこんな構造をして「いません」。どこかにCネイティブなAPIが隠れていてその上にC++がアドオンで乗っているわけではなく、図1のようにOSとアプリケーションの間にはどこまでもフレームワークが介在してくるオブジェクト指向環境です(注)。それでなくてはスマートフォンにおける最優先課題である省電力を実現することはできません。

※注:
P.I.P.S.というPOSIX準拠の環境がSymbian OS に導入されることがコミットされました。この件に関する解説は、基本部分についてひととおり終えた後にじっくり行おうと思いますので、しばらくお待ちください。


 詳細は次回以降に譲りますが、Symbian OSにはイベントウェイトに関してすべてのプログラムが適切に協調動作を行うためのフレームワークが存在します。Symbian OSの特徴である優れた省電力性は、このフレームワークを前提として構築されています。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.