第3回 CライブラリのWindowsランタイム・コンポーネント化戦略：連載：Windowsランタイム・コンポーネントによるコードの再利用（5/5 ページ）
既存のC／C++プログラムをWindowsランタイム・コンポーネント化する際に取れる戦略と、それぞれの特徴や、メリット／デメリットを考察する。
Windowsランタイム・コンポーネント作成時の注意事項
Windowsランタイム・コンポーネントの実装方法が決定したら、Visual Studio 2012の［Windows ランタイム コンポーネント］プロジェクト・テンプレートを利用して開発を行う。
開発時の注意事項として、デバッグ時のスタートアップ・アプリケーションにWindowsストア・アプリが必要だという点が挙げられる。もちろん、あらかじめ、作りたいWindowsストア・アプリが決まっていて、それにプロジェクトの追加の形式でWindowsランタイム・コンポーネントを作成する場合もあるだろう。
ここで、真に重要なのは、Windowsランタイム・コンポーネントの呼び出し側と呼ばれる側の双方からデバッグを行いたい場合は、JavaScriptアプリを選択してはならないという点だ。仮に作成目的のWindowsストア・アプリがJavaScriptだとしたら、デバッグ用のC#やC++/CXのアプリも用意したほうがよい。
というのは、Visual Studio 2012のデバッガは、以下の4種類しかないからだ（ただし、C++の場合はGPUのみという選択肢もあるが、この場合には適切ではない）。
- ［スクリプトのみ］： JavaScriptのみブレイク、ステップ実行などが可能。つまり、Windowsランタイム・コンポーネント側のステップやウォッチはできない
- ［ネイティブのみ］： C++/CXのみブレイク、ステップ実行などが可能。
- ［マネージのみ］： C#／VBのみブレイク、ステップ実行などが可能。
- ［混合（マネージとネイティブ）］： C#、VB、C++/CXのいずれもブレイク、ステップ実行などが可能。
仮にアプリケーションをJavaScriptで作成していて、Windowsランタイム・コンポーネントをC++/CXで作成しているとすると、［ネイティブのみ］のデバッガを選択してWindowsランタイム・コンポーネント側にブレイクを仕掛けてデバッグすることは可能だ。しかし、この場合、JavaScriptのWindowsランタイム・コンポーネント呼び出し直前にブレイクを入れたり、呼び出し直後にブレイクを入れて返り値をチェックしたりできない。同様に、スクリプトのみのデバッガを選択するとC++/CX側のデバッグはできない。
今回は、既存のC／C++ライブラリをWindowsランタイム・コンポーネント化する際に取れる戦略と、それらの特徴、メリット／デメリットなどについて検討した。次回はいよいよ、mrubyを実際にWindowsランタイム・コンポーネント化してみることにしよう。
Copyright© Digital Advantage Corp. All Rights Reserved.