Imagix 4D ユーザガイド
目次

Microsoft Visual C++ のサポート

タイプライブラリと #import

Microsoft Visual C++ では、COM 型の定義をタイプライブラリに格納することができます。これらの定義は、Microsoft 固有のプリプロセッサ・ディレクティブである #import を使用することによって、ソースコードで利用することができます。以下に例を示します。

#import <libraryname.tlb>

ファイルタイプの多くはタイプライブラリを組み込むことができ、MSVC コンパイラの #import ディレクティブを使用することでサポートされます。なかでも最も一般的なものが、タイプライブラリのバイナリファイル（.tlb）です。タイプライブラリには以下のような progid あるいは libid によって定義されたファイルのみならず、オブジェクト・ライブラリ（.olb）、実行ファイル（.exe）、ダイナミック・リンクライブラリ（.dll）も、組み込まれます。

#import "progid:my.prog.id.1.5"

もしくは

#import "libid:12341234-1234-1234-1234-1234" version("4.0") lcid("9")

.tlh ファイルの解析

Imagix 4D のソースアナライザが #import コマンドを処理する際、まず初めに同等のコンパイラによって生成されるプライマリ・ヘッダファイルのインクルードを試みます。libraryname.tlb もしくは libraryname.exe を指定する #import ディレクティブを認識すると、ソースアナライザは libraryname.tlh という名前のヘッダファイルを検索します。

そのような .tlh ファイルは、MSVCコンパイラによって作成され、既に各環境に作成されていることがあります。このファイルが存在しない場合は、コードにロードする前に、コンパイラの実行を選択することが可能です。コンパイラは通常、.tlb ファイルタイプに対応する .tlh ファイルを生成します。.olb、.exe、.dll ファイルなど他のタイプについては、.tlh ファイルが作成される場合と作成されない場合があります。MSVC コンパイラが、progid および libid ライブラリ名に対する .tlh ヘッダファイルを生成することはなく、また Imagix 4D のソースアナライザもそれらのライブラリ名をサポートしません。以上の内容に関する詳細は、Microsoft 社のドキュメントを参照してください。

Imagix 4Dのソースアナライザで既存の .tlh ファイルを検出するには、ソースアナライザに渡される -I および -S オプションで指定したインクルード・パスに、該当のファイルを保存する必要があります。通常は、Visual Studio プロジェクトへロードするため MSVC プロジェクトあるいは MSVC ワークスペース / ソリューションのデータソースを作成する際に、-I オプションおよび -S オプションが自動的に定義されます。.tlh ファイルが存在するにもかかわらず警告メッセージが出力される場合には、-I オプションを追加してファイルが格納されているディレクトリを指定する必要があります。この追加の -I オプションは、[データソース] ダイアログの [プロジェクト] タブにある [オプション] フィールドで指定します。

多くの場合プライマリ・ヘッダファイル（.tlh）には、セカンダリ・ヘッダファイル（.tli）を指し示す #include ディレクティブが記述され、このセカンダリ・ヘッダファイルにはコンパイラが生成するメンバ関数が定義されます。警告メッセージが .tlh ファイルではなく .tli ファイルが見つからないことを示す場合、.tli ファイルが存在することを再度チェックし、MSVC コンパイラを実行して欠如しているファイルの生成を試みる必要があります。しかしながら大半のケースにおいて、検出できない .tli ファイルは Imagix データソースに情報を格納しないため、無視してもあまり問題はありません。

.inc ファイルの解析

.tlh ファイルが存在しなかったり、検出できなかったりする場合、アナライザは次に同等の .inc ファイルを検索します。この .inc ファイルは Imagix 4D 固有の設定ファイルであり、指定されたタイプライブラリにあるクラスや型の定義が記述されています。これらの定義は、.tlh ヘッダファイルで検出されるものに類似するものです。ソースアナライザは libraryname.tlb に対して、libraryname.tlb.inc とう名前の .inc ファイルを検索します。同様に libraryname.dll の場合、検索の対象となるファイル名は ibraryname.dll.inc です。

ソースアナライザは、-I ならびに -S オプションで指定されたインクルード・パス上にある、これらの .inc ファイルをチェックします。さらに Linux / Unix においては、インストレーション・パス ../imagix/user/cc_cfg/msvc_lib も確認の対象となります。検出された該当の .inc ファイルは、.tlh ヘッダファイルやコンパイラ設定ファイルと同じように、ソースコードとして解析されます。

.inc ファイルの生成

.inc ファイルが検出されない場合はオペレーティング・システムによって、ソースアナライザの次の動作が異なります。Windows の環境で Imagix 4D のソースアナライザが同等の .tlh もしくは .inc ファイルを見つけられないケースにおいて、アナライザはオリジナルの .tlb、.olb、.exe、あるいは .dll タイプライブラリ・ファイルの処理を試みます。ソースアナライザは、タイプライブラリのロードに Windows システムコール LoadTypeLib() を使用します。LoadTypeLib() のファイル検索のプロセスについては、Microsoft 社のドキュメントを参照してください。

ソースアナライザがバイナリのタイプライブラリ・ファイルを検出すると、そのファイルを処理し同ファイルに記述されているクラスおよび型定義を包含する .inc ファイルを生成します。ソースアナライザのオプション -dotnetfuncs を使用する場合、メンバ関数の宣言も .inc ファイルに組み込まれます。.inc ファイルは、プロジェクト固有のディレクトリである ../project.4D/inc に格納されます。その後、.inc ファイルはソースコードとして解析され、この結果、クラス、型、さらにオプションで関数の宣言がロードされるのです。

Windows の環境において、ソースアナライザがタイプライブラリ・ファイルを検出できない場合、次のような警告メッセージが生成されます。

could not open libraryname.tlb

Linux / Unix 環境で MSVC コードの解析を実行しているクロスプラットフォーム開発では、オリジナルの .tlb、.olb、.exe あるいは .dll タイプライブラリを処理することができないため、.inc ファイルは生成されません。このため一致する .inc ファイルが検出されないと、ソースアナライザは単純に以下の警告メッセージを出力します。

#import could not locate libraryname.tlh containing C++ definitions for type library

そのような状況における対処方法は、まず Windows の環境でコードを解析し、関連の .inc ファイルを作成します。次に Linux / Unix 環境で、ソースアナライザが生成した .inc ファイルを ../project.4D/inc ディレクトリから ../imagix/user/cc_cfg/msvc_lib ディレクトリへコピーすることで、Imagix 4D を継続することが可能です。

Imagix 4D は、警告が生成されてもソースコードをロードする、という点に注意してください。#import ファイルが見つからないという警告が出力されていてもメッセージがレポートされなければ、その警告を無視して、ソースコードの解析が正常に完了したと捉えることができます。さらに、空のテキストファイルを適切な名前で作成し、そのファイルを通常のヘッダファイルとともにインクルード・ディレクトリの1つに格納することで、検出できないファイルに関する警告を抑制することが可能です。

.NET CLR（マネージドコード）ファイルと #using

.NET フレームワークの共通言語ランタイム（CLR：Common Language Runtime）において Microsoft Visual C++ は、他の実行モジュールに定義されるシンボルの使用をサポートするために、別の方法を提供しています。#using プリプロセッサ・ディレクティブは、CLR の .dll、.exe、.netmodule、.obj の各ファイルに定義されたシンボルへの参照を可能とします。以下に例をあげます。

#using <System.Windows.Forms.dll>

CLR の設定

Microsoft Visual C++ のコンパイラ設定ファイルである msvc_win.inc には、共通言語ランタイムをサポートするための特殊なディレクティブが記述されています。これらのディレクティブを認識するには、Imagix 4D プロジェクトのデータソースを、-D_MANAGED あるいは -clr オプションを使用して定義する必要があります。通常は、CLR ベースの Visual Studio プロジェクトをロードするために、MSVC プロジェクトもしくは MSVC ワークスペース / ソリューションのデータソースを作成すると、自動的に -clr オプションが定義されます。

オプションは、[プロジェクト] > [データソース] ダイアログの適切なフィールドに設定する必要があります。Microsoft Visual Studio データソースの場合は、[プロジェクト] または [ソリューション] タブにある [オプション] フィールドが該当します。ダイアログ・ベース（C/C++）のデータソースでは、[ソースファイル] タブにある [PPフラグ] です。

.inc ファイルの解析

#using ディレクティブを認識すると、アナライザは即座に同等の .inc ファイルを検索します。この .inc ファイルは Imagix 4D 固有の設定ファイルであり、CLR ファイルに存在するクラスや型の定義が記述されています。ソースアナライザが、System.Windows.Forms.dll の .inc ファイルの検索に使用するファイル名は、System.Windows.Forms.dll.inc です。

ソースアナライザは、-I ならびに -S オプションで指定されたインクルード・パス上にある、これらの .inc ファイルをチェックします。さらに Linux / Unix においては、インストレーション・パス ../imagix/user/cc_cfg/msvc_lib も確認の対象となります。検出された該当の .inc ファイルは、コンパイラ設定ファイルと同様に、ソースコードとして解析されます。

.incファイルの生成

.inc ファイルが検出されない場合はオペレーティング・システムによって、以降のソースアナライザの動作が異なります。Windows の環境で Imagix 4D のソースアナライザが同等の .inc ファイルを見つけられないケースにおいて、アナライザはオリジナルの .dll、.exe、.netmodule あるいは .obj CLR ファイルの解析を試みます。ソースアナライザは、-I や -S オプションで指定されたディレクトリのみならず、FRAMEWORKDIR および FRAMEWORKVERSION 環境変数によって指定されたディレクトリも同様にチェックします。

ソースアナライザがバイナリ CLR ファイルを検出すると、そのファイルを処理し同ファイルに記述されているクラスおよび型定義を包含する .inc ファイルを生成します。ソースアナライザのオプション -dotnetfuncs を使用する場合、メンバ関数の宣言も .inc ファイルに組み込まれます。.inc ファイルは、プロジェクト固有のディレクトリである ../project.4D/inc に格納されます。その後、.inc ファイルはソースコードとして解析され、この結果、クラス、型、さらにオプションで関数の宣言がロードされるのです。

Windows の環境において、ソースアナライザが CLR ファイルを検出できない場合は、次のような警告メッセージが生成されます。

could not find mscorlib.dll

Linux / Unix 環境で MSVC コードの解析を実行しているクロスプラットフォーム開発では、オリジナルの.dll、.exe、.netmodule あるいは .obj CLR ファイルを処理することができないため、.inc ファイルは生成されません。このため一致する .inc ファイルが検出されないと、ソースアナライザは単純に以下の警告メッセージを出力します。

#using could not locate mscorlib.dll.inc containing C++ definitions for assembly

このように参照される最も一般的な MSVC 実行モジュールは、mscorlib.dll です。Imagix 4D の環境には、このファイルに相当するヘッダファイルとして mscorlib.dll.inc が用意されています。このファイルはインストレーション・ディレクトリ ../imagix/user/cc_cfg/msvc_lib に格納され、Linux / Unix 環境の場合は、暗黙の -S オプションが自動的に指定されます。したがって、#using <mscorlib.dll> という特定のディレクティブが既にサポートされていることになります。Windows の環境で mscorlib.dll を検出できない場合の最も簡単な対処方法は、mscorlib.dll.inc を ../imagix/user/cc_cfg へコピーすることです。

Imagix 4D は、警告が生成されてもソースコードをロードする、という点に注意してください。#using ファイルが見つからないという警告が出力されていてもメッセージがレポートされなければ、その警告を無視して、ソースコードの解析が正常に完了したと捉えることができます。さらに、空のテキストファイルを適切な名前で作成し、そのファイルを通常のヘッダファイルとともにインクルード・ディレクトリの1つに格納することで、検出できないファイルに関する警告を抑制することが可能です。

複数の DLL とクラスのエクスポート / インポート

コンパイラの標準的な動作では、同一コンパイル単位（実行ファイル、DLL、ライブラリ）内で同じ名前を持つ最上位クラスはすべて、同じクラスであると見なすグローバル命名規則が適用されます。Microsoft Visual C++ も、このルールに従います。さらに実行モジュールあるいは DLL それぞれに対して Imagix 4D のプロジェクトを作成している限り、Imagix 4D ソースアナライザはデフォルトでこの動作をサポートします。

しかし、複数のコンパイル単位に及ぶプロジェクトを定義する必要が生じる場合があります。そのようなケースでは、別々のコンパイル単位において、実際には異なるクラスに同じ最上位クラスの名前を再利用することが、偶発する可能性があるのです。このような名前の衝突は、ソースアナライザのオプション -uaggr（ユニークな集合）を適用することで、防止することができます。-uaggr オプションが使用されると、他のファイルで定義された最上位クラスはすべて、たとえ同一の名前であったとしても、別々のクラスであると見なされます。

これによって、最上位クラスの名前の衝突に関する、大半の問題に対処することができます。ただし Microsoft Visual C++ では、コンパイル単位の境界を越えて、最上位クラスを共有することが可能です。MSVC では拡張機能の dllexport および dllimport によって、特定のクラスを拡張 DLL として定義することができます。そのようなクラスは、1つの DLL によって定義され、それらが使用される他の DLL 内で宣言されるのです。その一方で、通常のクラスは単に1つの DLL として引き続き拡張されます。

Imagix 4D は、そのような状況に対応することが可能です。通常のクラス間における名前の衝突を回避するには、-uaggr オプションを使用しなければなりません。DLL を拡張する単一のクラスとして、拡張機能の dllexport および dllimport によって指定されたクラスを認識するためには、Imagix 4D の混合プロジェクト機能の使用が推奨されます。この方法では、各 DLL に個別の Imagix 4D プロジェクトが作成されるのです。その後、個々のプロジェクトが混合プロジェクトに結合されます。

この手法の別の利点は、DLL 単体のみを調べたい場合に、最終的に個々のプロジェクトがフォーカスされることにあります。さらに、複数の実行モジュールと DLL を対象にシステム全体を調べる必要がある場合には、混合プロジェクトを活用して、その調査を行うことが可能です。混合プロジェクトに関する詳細は、本ユーザガイドに記載のプロジェクトとデータ収集のセクション内の混合プロジェクトのページを参照してください。