 | ||||||||||
| ||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
| ||||||||||
| 2つのアプローチ | ||||||||||
残念ながら、Cをベースにしたダイナミック言語の実装とC++やCのアプリケーションを統合するにはいくつかの課題があります。なぜなら多彩なアプローチの方法やアプリケーションアーキテクチャが存在するためであり、このようなシステムにはJavaと違ってそのベースに一貫したVMがないためです。 ミドルウェアシステムは通常ループやマルチスレッドなどの機能を利用していますが、アプリケーションからすれば、そのような機能によって完全にコントロールされていると解釈されます。しかし、実際にはインテグレーションの問題が内在することになります。 C++やCのミドルウェアの一部とダイナミック言語を組み合わせることにより、たいていダイナミック言語でミドルウェアをラッピングするような結合力の強いアプリケーションの作成が行えます。このようなステップを取ることにより、開発担当は直接ダイナミック言語を扱うことができるので、ミドルウェアは実装の詳細な部分として隠蔽されるようになります。 Cベースのダイナミック言語をC++やCのミドルウェア上で実装してレイヤを構成する場合、一般的にダイナミック言語とミドルウェアの間に「連携用のコード」が必要となります。そのため開発担当者はそのようなコードを個別に作成したり、コード生成ツールを利用します。 C++やCのコードをダイナミック言語と統合する際に自動的にコードを生成するツールの中でお薦めできるものとしては、「Simplified Wrapper and Interface Generator（SWIG）」があります。 Simplified Wrapper and Interface Generator http://www.swig.org 開発担当者はダイナミック言語へインポートする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を使ってみようというのであれば、一般的には、独自の連携用コードを設計して、実装することをお薦めします。 | ||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
Translated from the original English version and reprinted with permission, from "Ruby Extension" IEEE Internet Computing September/October 2006 issue of the "Toward Integration" column, by Steve Vinoski, vol. 10, no. 5, 2006, pp. 81-83. (c) 2006 IEEE. This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of Think It's products or services. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to pubs-permissions@ieee.org. By choosing to view this document, you agree to all provisions of the copyright laws protecting it. | ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||
-
人気記事ランキング
-
-
連載
