0

Win32 API の ReadFile 関数について 2 つの質問がありました。まず第一に、それを考えると

BOOL WINAPI ReadFile(
                       _In_         HANDLE hFile,
                       _Out_        LPVOID lpBuffer,
                       _In_         DWORD nNumberOfBytesToRead,
                       _Out_opt_    LPDWORD lpNumberOfBytesRead,
                       _Inout_opt_  LPOVERLAPPED lpOverlapped
                    );

3 番目と 4 番目のパラメーターは DWORD 型で、オーバーフローなしで最大 1^32 を保持できます。ReadFile は、一度に 1^32 バイト未満のデータを持つファイルしか読み取れないということですか? そうであれば、1^32 より大きいファイルを読みたいので、ReadFile を次のようなループに入れます。

char buffer[1<<32];
while(!EOF){
  ReadFIle(filename,buffer,1^32,bytesout,NULL);
  SomeFunctionToExtractDataFromBuffer(buffer)
}

ループが反復ごとにバッファを上書きする傾向があると仮定すると、この設計が機能するために、ReadFile はファイル内で以前の読み取りが行われた場所を記憶する必要がありますか? または、これを達成する他の方法があります。どうもありがとう

4

1 に答える 1

3

3 番目と 4 番目のパラメーターは DWORD 型で、オーバーフローなしで最大 1^32 を保持できます。ReadFile は、一度に 1^32 バイト未満のデータを持つファイルしか読み取れないということですか?

いいえ。一度に 2^32 バイトまでしか読み取れないことを意味します。ReadFile合計で好きなだけバイトを読み取るために複数回呼び出すことを止める人は誰もいません (読み取りごとにファイル ポインターが進むため、前回の読み取りが停止したポイントから読み取りが開始されます)。

ループが反復ごとにバッファを上書きする傾向があると仮定すると、この設計が機能するために、ReadFile はファイル内で以前の読み取りが行われた場所を記憶する必要がありますか?

はい、OS は開いているすべてのファイルについてこれを記憶しています (上記のファイル ポインタのリンクを参照してください)。

この件に関しては、4 GB の読み取りをスケジュールしている場合は、おそらく何か間違ったことをしている可能性が高いことに言及する必要があります。データの性質が何であれ、それを小さなチャンクで処理できることは確かです。これにより、使用可能なメモリなどのさまざまな問題に直面するのを防ぐことができます。

于 2012-09-29T18:04:16.960 に答える