0

一部の API では文字数が必要です。

// Why did they choose cch in these functions.
HRESULT StringCchCopyW(
  __out  LPWSTR pszDest,
  __in   size_t cchDest,
  __in   LPCWSTR pszSrc
);

errno_t wcscpy_s(
   wchar_t *strDestination,
   size_t numberOfElements,
   const wchar_t *strSource 
);

DWORD WINAPI GetCurrentDirectoryW(
  __in   DWORD nBufferLength, // Count of Chars
  __out  LPWSTR lpBuffer
);

また、一部の API ではバイト数が必要です。

// What do you prefer cch vs cb function.
// Do cch functions almost useful?
HRESULT StringCbCopyW(
  __out  LPWSTR pszDest,
  __in   size_t cbDest,
  __in   LPCWSTR pszSrc
);

BOOL WINAPI ReadFile(
  __in         HANDLE hFile,
  __out        LPVOID lpBuffer,
  __in         DWORD nNumberOfBytesToRead,
  __out_opt    LPDWORD lpNumberOfBytesRead,
  __inout_opt  LPOVERLAPPED lpOverlapped
);

// Why did they choose cb in these structures.
// Because there are some apis uses cb, I always should see MSDN.
typedef struct _LSA_UNICODE_STRING {
  USHORT Length; // Count of bytes.
  USHORT MaximumLength; // Count of bytes.
  PWSTR  Buffer;
} UNICODE_STRING, *PUNICODE_STRING;

typedef struct _FILE_RENAME_INFO {
  BOOL   ReplaceIfExists;
  HANDLE RootDirectory;
  DWORD  FileNameLength; // Count of bytes.
  WCHAR  FileName[1];
} FILE_RENAME_INFO, *PFILE_RENAME_INFO;

関数またはデータ構造を設計するとき、cb または cch をどのように決定しますか? なぜ？
呼び出し元の API をより適切に設計するには、これについて何を知っておく必要がありますか?

4

2 に答える 2

3

返されるデータが文字列の場合、バイト数は役に立たないことが多いため、文字数を返す必要があります。しかし、それが一般的なバイナリ データ (具体的には文字列ではない) の場合、明らかに文字数は意味をなさないので、バイト数を使用します。

理由について：

バイト数を保持する理由は、 NtCreateFileで使用さLSA_UNICODE_STRINGれる と互換性があるためだと思います。しかし、文字列ではなく値を指すように実際に扱うパラメーターを受け取ります...全体的に貧弱な設計だったと思いますが、バイト数はそこでより理にかなっています:UNICODE_STRINGNtCreateFileFILE_OPEN_BY_FILE_IDUNICODE_STRINGLONGLONG

FILE_OPEN_BY_FILE_ID:ObjectAttributesパラメーターで指定されたファイル名には、ファイルの 8 バイトのファイル参照番号が含まれています。

于 2011-01-28T05:25:56.807 に答える
0

お気づきのとおり、最初に言及した関数のグループはすべて ASCII 関数であるため、その場合は違いはありません。バイト数は文字数です。これは、(一般的にはとにかく) 1 つの ASCII 文字のサイズが正確に 1 バイトであるためです。

2 番目のグループは、Unicode 関数/構造体です。この場合、文字のサイズが 1 バイトだけであるとは限りません。UTF16 形式の場合は 2 バイト幅、UTF32 の場合は 4 バイト、UTF8 の場合は (通常) 1 ～ 4 バイト幅。

特に UTF8 データの場合、バッファーを作成する場合、通常、特定のバイト数を確保します。これは、文字サイズに応じて、文字数に関して非常にさまざまな長さになる可能性があります。私はあなたが提示したほとんどの関数/構造体にあまり精通していませんが、それが何か関係があるとしても驚かないでしょう.

あなたの質問に答えるために、ASCII を使用している場合は、どちらのアプローチも使用できます。違いはありません。ただし、可変長エンコーディング (UTF8 など) を使用する場合、どちらを使用するかは、関連する文字だけに関心があるか、またはそれらのエンコーディングも考慮する必要があるかによって異なります。

于 2011-01-28T06:11:24.863 に答える