![]() |
![]() |
|
|
コードの移植性
IDL コンパイラからの出力は、多数の環境でコンパイルできるように作成されます。コンパイル作業の説明は次の章を参照してください。ただし、環境によっては動作に支障が起きる構成もあります。既知の問題点を以下に示します。
ANSI に準拠しない旧形式の C 言語を使用してコンパイルする場合、「配列へのポインタ」は許可されません。例を示します。
typedef long array[10][10];
func()
{
array t1;
array *t2;
t2 = &t1; /* & ignored, invalid assignment */
func2(&t1); /* & ignored */
}
このため、移植を考慮した場合、「配列へのポインタ」をパラメータとして、オペレーションに渡すことが難しくなります。
文字列属性がマルチ・バイト構造体に適用されるところに文字列の配列を使用すると、コンパイラが構造体に文字を埋め込むときに期待する結果が得られないことがあります。これは通常は起こり得ません。ほとんどのコンパイラは文字フィールドのみを含む構造体には文字の埋め込みは行いません。しかし、この現象は少なくとも一度確認されています。
デフォルトでは、定数値のインプリメントは各定数に対して #define を作成することで行われます。このため、定数に用いる名前は、IDL ファイル内やインポートされたすべての IDL ファイル内のほかのすべての名前と同じ名前にしてはいけません。ANSI C 環境でこの問題を回避するには、tidl コンパイラの TxRPC 固有のオプション _use_const を使用します。このオプションを使うと、#define 定義の代わりに、const 宣言が作成されます。定数値はクライアント・スタブとサーバ・スタブ内で宣言されます。ヘッダ・ファイルをインクルードするほかのすべてのソース・ファイルでは、単に extern const 宣言が使用されます。こうしないと、クライアント・スタブとサーバ・スタブを同一の実行ファイルにコンパイルできないという制限を生じるか、二重定義エラーが発生することに注意してください。
C++ 環境では、次のような制限があります。
struct t1 {
long s1;
};
typedef struct t1 t1; /*正常*/
typedef long t1; /*エラー*/
struct t1 {
struct t2 {
long s2;
} s1;
} t1;
typedef struct t3 {
struct t2 s3; /*t2 は未定義エラー */
} t3;
long *ptr;
ptr = (long *)malloc(sizeof(*ptr) * 4);
クライアントとサーバのアプリケーション・ソフトウェアをコーディングしているときは、IDL コンパイラが作成したデータ型、すなわち rpc/tidlbase.h 内で定義されるデータ型を使う必要があります。(rpc/tidlbase.h 内での定義とは、 次の表に 「発行されるマクロ」として記載されているものです。)たとえば、idl_long_int の代わりに long を使うと、データ型はプラットフォームによっては 32 ビットであったり 64 ビットであったりします。一方、idl_long_int は全プラットフォームで 32 ビットです。作成されるデータ型の一覧を表 3-1 に示します。
生成されるデータ型
C の場合と同様、IDL でも複数のクラスの識別子があります。スコープや名前空間などのクラス内では、名前を一意にする必要があります。
タグを持たず、typedef の一部として定義されていない匿名の構造体または共用体は、オペレーションの戻り値やパラメータとして使用できないことに注意してください。
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|