Rubyの拡張によるアプローチの違い
2つのアプローチ
残念ながら、Cをベースにしたダイナミック言語の実装とC++やCのアプリケーションを統合するにはいくつかの課題があります。なぜなら多彩なアプ ローチの方法やアプリケーションアーキテクチャが存在するためであり、このようなシステムにはJavaと違ってそのベースに一貫したVMがないためです。
ミドルウェアシステムは通常ループやマルチスレッドなどの機能を利用していますが、アプリケーションからすれば、そのような機能によって完全にコントロールされていると解釈されます。しかし、実際にはインテグレーションの問題が内在することになります。
C++やCのミドルウェアの一部とダイナミック言語を組み合わせることにより、たいていダイナミック言語でミドルウェアをラッピングするような結合 力の強いアプリケーションの作成が行えます。このようなステップを取ることにより、開発担当は直接ダイナミック言語を扱うことができるので、ミドルウェア は実装の詳細な部分として隠蔽されるようになります。
Cベースのダイナミック言語をC++やCのミドルウェア上で実装してレイヤを構成する場合、一般的にダイナミック言語とミドルウェアの間に「連携用 のコード」が必要となります。そのため開発担当者はそのようなコードを個別に作成したり、コード生成ツールを利用します。
C++やCのコードをダイナミック言語と統合する際に自動的にコードを生成するツールの中でお薦めできるものとしては、「Simplified Wrapper and Interface Generator（SWIG）」があります。
開発担当者はダイナミック言語へインポートするC++やCで宣言するインターフェース記述を作ります。そこにはSWIGツールがダイナミック言語と 連携するコンベンションとコントラクトなどと機能を緊密に接続するコードを生成します。このようなコードはライブラリに格納されており、必要に応じてダイ ナミック言語がロードします。このようにして、SWIGは、Rubyなどの多くのダイナミック言語をサポートしています。
しかしSWIGはいかなる時にも利用できる万能薬ではありません。生成されたコードでは、JavaやC++のオブジェクトをWebサービスとして公 開した時に発生するインピーダンスミスマッチの問題があります。ほかにもSWIGがダイナミック言語の環境に適用するC++やCの関数は、スタイルや粒度 の問題で適合しない場合があります。
必要なものを簡単に作る
ここで1つの例をあげます。筆者が原稿執筆に利用しているPowerBook G4は、時々AC電源コードが抜けてバッテリ動作となっていながらも、バッテリ低下のアラームが鳴るまで気が付かないことが多々あります。
そこでMac OS X 10.4のIOKitフレームワークを使って、バッテリや電源に関する情報を得るアプリケーションを作成しました。C++やC、Object-Cを使って このような処理を実行するアプリケーションを書きたいとは思わなかったので、Rubyを使って書くことに決めました。ここではRubyのレベルのフレーム ワーク機能があるSWIGを使うことにしたのです。
このフレームワークを使うことにより、動作しているのがAC電源なのかバッテリかが判別できる以外にも、バッテリ残量までもわかります。さらにAC電源からバッテリに切り替わったときにポップアップして警告することもできます。
IOKitフレームワークで必要なのは、C言語における3つの関数だけなので、まずその関数が宣言されているヘッダファイルの処理を行うために SWIGを入手しました。しかしSWIGのパーザーは単なるtypedefによる関数のポインタ表現も解釈できないので、3つの関数を手作業で明示的に公 開するようにしてみました。
すると作成したアプリケーションは概ねうまく動いたのですが、Rubyから関数を呼び出すとき、関数の入出力の値が他のCの関数でしかアクセスできない曖昧なデータ型となることがわかったのです。
データの操作や曖昧なデータ型を扱わなければならないアクセス機能の公開にSWIGを使うことができます。しかしこのようなアプローチの問題は、公開した機能の粒度がRuby言語に合わないことです。
なぜならRubyはオブジェクト指向の傾向が強いのですが、このような機能を通常のRubyのクラスやオブジェクトに当てはめることができません。 さらにメモリ管理機能を利用する必要がありますが、このような手法はダイナミック言語ユーザの好みではないようです。
SWIGのデータ型のマップ機能を利用して、フレームワークの型とRubyの型を対応させるコードを生成したコードにうまく差し込むことができたの ですが、typemaps（データ型変換スクリプト）による変換では、ある問題が解決できないこともあります。もしtypemapsが使えたとしても、連 携用のコードを独自に書いたと思われるので、結果的にはSWIGは選ばずにCで独自のRuby連携用のコードを書いています。
また、SWIGを別のC++のフレームワークをもったミドルウェアプロジェクトに使ってみましたが、同じような問題が発生しました（このケースで も、SWIGを使わずに独自の連携用のコードを書いています）。SWIGは元となるコードがダイナミック言語のスタイルにあったものでないとうまく動作し ないようです。もしSWIGを使ってみようというのであれば、一般的には、独自の連携用コードを設計して、実装することをお薦めします。
