次の方法で共有

byte_count属性

  • [アーティクル]

[byte_count] ACF 属性は、サイズ (バイト単位) とポインターによって示されるメモリ領域を関連付けるパラメーター属性です。

[ function-attribute-list ] function-name(
    [byte_count(length-variable-name)] parameter-name);
    ...);

パラメーター

function-attribute-list

0 個以上の ACF 関数属性を指定します。

function-name

IDL ファイルで定義されている関数の名前を指定します。 関数名は必須です。

length-variable-name

パラメーター名で参照されるメモリ領域のサイズ (バイト単位) を指定する [in]専用 パラメーターの名前を指定します。

parameter-name

IDL ファイルで定義されている [out]専用ポインター パラメーターの名前を指定します。

解説

ACF 属性 [byte_count] は 、DCE IDL に対する Microsoft 拡張機能を表します。 したがって、MIDL コンパイラ スイッチ /osf を使用する場合、この属性は使用できません。

注意

[byte count] 属性は、すべての [out] パラメーターに必要なサイズの見積もりが困難なため、NDR64 構文ではサポートされなくなりました。

 

ポインター パラメーターによって参照されるメモリは連続しており、クライアント スタブによって割り当ても解放もされません。 [byte_count] 属性のこの機能を使用すると、リモート プロシージャへの複数の呼び出し中に再利用できる永続的なバッファー領域をクライアント メモリに作成できます。

クライアント スタブ メモリ割り当てをオフにすることで、効率を高めるためにアプリケーションを調整できます。 たとえば、[ byte_count] 属性は、Microsoft RPC を使用するサービス プロバイダー関数で使用できます。 ユーザー アプリケーションがサービス プロバイダー API を呼び出し、バッファーへのポインターを送信すると、サービス プロバイダーはバッファー ポインターをリモート関数に渡すことができます。 サービス プロバイダーは、ユーザーにメモリ領域の再割り当てを強制することなく、複数のリモート呼び出し中にバッファーを再利用できます。

メモリ領域には、複数のポインターで構成される複雑なデータ構造を含めることができます。 メモリ領域は連続しているため、アプリケーションは、各ポインターと構造体を個別に解放するために複数の呼び出しを行う必要はありません。 代わりに、メモリ割り当てまたは空きルーチンを 1 回呼び出して、メモリ領域を割り当てたり解放したりすることができます。

バッファーは [out] 専用パラメーターである必要があり、バッファーの長さ (バイト単位 ) は [in] 専用パラメーターである必要があります。

すべての [out] パラメーターを格納するのに十分な大きさのバッファーを指定します。 埋め込みが隠されているため、正確なカウントではなく過大評価を使用します。 たとえば、4 バイト のポインターは、32 ビット プラットフォームでは 4 バイトのアライン境界で、64 ビット プラットフォームでは 8 バイト境界上の 8 バイト ポインターではマーシャリングされません。 したがって、スタブが実行するアラインメント パディングは、バッファーの領域で考慮する必要があります。 さらに、C 言語のコンパイル中に使用されるパッキング レベルは異なる場合があります。 C 言語のコンパイル時に使用されるパッキング レベルに追加された追加のパッキング バイトを考慮するバイト数の値を使用します。 32 ビット プラットフォームと 64 ビット プラットフォームの両方をカバーする安全な方法は、ビッグ メモリ ブロックに入る各オブジェクトが 8 の倍数のアドレスから始まると想定することです。

例

/* IDL file */ 
HRESULT proc1([in] unsigned long length, 
              [out] struct my_struct * pMyStruct); 
 
/* ACF file */ 
proc1([byte_count(length)] pMyStruct);

関連項目

アプリケーション構成ファイル (ACF)

インチ

length_is

/Osf

乙

size_is