最終回　実際にC++/CXでWindowsランタイム・コンポーネントを作成する：連載：Windowsランタイム・コンポーネントによるコードの再利用（1/3 ページ）

powered by Insider.NET

連載目次

　前回は、既存のC／C++ライブラリをWindowsランタイム・コンポーネント化する際に取れる戦略と、それらの特徴、メリット／デメリットなどについて検討した。連載第2回ではmrubyをコンパイルしたが、今回は、そのmrubyを組み込んだWindowsランタイム・コンポーネントをC++/CXを使って実際に作ってみよう。

　ここでは、前回に説明したmrubyを組み込んだファサード・パターンのコンポーネントとする。なお、完全なソース・ファイルは、https://github.com/arton/MrbFacadeにある*1。

プロジェクトの作成

　C++/CXでWindowsランタイム・コンポーネントを作成するには、Visual Studio 2012のメニューバーから［ファイル］−［新規作成］−［プロジェクト］を選択して、［新しいプロジェクト］ダイアログで［Visual C++］−［Windows ストア］−［Windows ランタイム コンポーネント］を選択する（以下の画面を参照）。ここでは、mrubyのファサード（facade）とするので、プロジェクト名に「MrbFacade」と入力している。

Windowsランタイム・コンポーネント・プロジェクトの新規作成

　プロジェクトを作成すると、ソリューション・エクスプローラには、以下のテンプレートが用意された状態となる。

作成直後のWindowsランタイム・コンポーネント・プロジェクト

プロジェクトを構成するファイル

　このプロジェクトには以下のような.cpp／.hファイルが含まれている。

• Class1.cpp： Class1のコンストラクタのプレースホルダ。プロジェクト名の名前空間とPlatform名前空間の“using”は指定済み。MrbFacadeでは、このファイルをMrbFacade.cppにリネームして、ここにクラスの実装を記述している
• Class1.h： Class1の定義。プロジェクト名を名前空間として設定済み。上と同様、MrbFacadeでは、このファイルをMrbFacade.hにリネームしている
• pch.cpp： プリコンパイル・ヘッダ用ソース・ファイル。このファイルはpch.hファイルをプリコンパイルするために用意されているだけなので、編集の必要はない
• pch.h： プリコンパイル・ヘッダ用ヘッダ・ファイル。プリコンパイルしたいヘッダ・ファイルをincludeする

　また、外部依存関係として、次の2つの.winmdファイルがあらかじめ組み込まれている。

• platform.winmd： Platform名前空間（WindowsランタイムABI）
• Windows.winmd： Windows名前空間（Windowsランタイム）

　このように、生成されるテンプレート・ファイルについては、外部依存関係の既定の設定を除けば一見するとWindowsランタイム・コンポーネントだからといって特に変わった点はない。

Windowsランタイム・コンポーネント・プロジェクトのコンパイル・オプション

　Windowsランタイム・コンポーネント・プロジェクトの重要な設定は、コンパイル・オプションにある（以下の画面を参照）。

Windowsランタイム・コンポーネント・プロジェクトのコンパイル・オプション

　上の画面を見ると、CLRの利用に関する［共通言語ランタイム サポート］が空欄（＝利用しない）となっている代わりに、［Windowsランタイム拡張機能の使用］が［はい（/ZW）］となっていることが分かる。

　/ZWオプションによってWindowsランタイム言語拡張機能が有効となり（つまり、C++/CXを指定したことになり）、Windowsストア・アプリで利用できないランタイム関数の呼び出しはコンパイル時に検出されてエラーとなる。また、/ZWを設定すると、CLRは利用できなくなる。

　なお、オプションについては、MSDNサイトの「コンパイラとリンカーのオプション (C++/CX)」で解説されている。また、Debugビルドでは、/RTC1（MSDNサイトの「/RTC (ランタイム エラー チェック)」を参照）によってランタイムエラー・チェックが有効になるが、このオプションを設定して生成したプログラムはWindowsストア・アプリの審査を通らないことには注意してほしい。Windowsストア・アプリをリリースする場合は、必ずReleaseビルドが必要である。

mrubyへの参照を追加する

　それ以外の点については、通常のVisual C++のプロジェクトと同様に考えてよい。従って、mrubyをライブラリとして利用する場合は、標準的な方法、つまりmruby関連のヘッダ・ファイルを取り込むためのインクルード・ディレクトリを設定し、mrubyのライブラリ・ファイルを入力ライブラリとして設定する。

　以下で行う設定は、Debug、Releaseのいずれのビルドでも必要となるため、設定漏れを避けるために、あらかじめプロパティ・ページの［構成］を［すべての構成］にしておくことが望ましい。

　なお、以下で参照するmrubyディレクトリは、第2回でmrubyをコンパイルしたときにソース・ファイルを展開したディレクトリである。読者が自分でmrubyをコンパイルしているときには「mruby\include」ディレクトリなどは対応するディレクトリに適宜読み替えてほしい。

• includeディレクトリの追加： ソリューション・エクスプローラもしくは［プロジェクト］メニューからプロジェクトの［プロパティ］を選択して、そのプロパティ・ページで［C/C++］−［全般］の［追加のインクルード ディレクトリ］に「mruby\include」を追加
• libディレクトリの追加： ソリューション・エクスプローラもしくは［プロジェクト］メニューからプロジェクトの［プロパティ］を選択して、そのプロパティ・ページで［リンカー］−［全般］の［追加のライブラリ ディレクトリ］に、libmruby.libファイルを配置したディレクトリを設定する（前回示したクロスコンパイル設定を利用した場合は「mruby\build\nostdio\lib」ディレクトリとなる）
• 入力ライブラリの追加： ソリューション・エクスプローラもしくは［プロジェクト］メニューからプロジェクトの［プロパティ］を選択して、そのプロパティ・ページで［リンカー］−［入力］の［追加の依存ファイル］に、libmruby.libファイルを追加する

　また、mrubyのヘッダ・ファイルで構造体のレイアウトに影響するため、「DISABLE_STDIO」をプロジェクトのプロパティ・ページから［C/C++］―［プリプロセッサ］の［プリプロセッサの定義］に追加する。

　プロジェクトの構成ができたら、次にMrbFacadeで実装するAPIについて検討してみよう。