0

peek メソッドに関する多くの質問を見ましたが、私の質問は、ほとんど明白であるにもかかわらず (私が思うに) 興味深いトピックに関するものです。

読み取るバイナリ ファイルがあり、それをプログラム メモリ内で全体として表示し、読み取りを実行するために istringstream オブジェクトを使用することを選択したとします。

たとえば、ストリーム内の特定のバイトの位置を検索している場合、ハードディスクに繰り返しアクセスすると、時間とリソースが無駄になります...

ただし、istringstream オブジェクトを作成すると、最終的な NULL バイトはすべて EOF シグナルとして扱われます。

少なくとも、これは次の短いコードで私に起こったことです:

                 // obvious omissis
                 std::istringstream is(buffer);
                 // where buffer is declared as char *
                 // and filled up with the contents of
                 // a binary file
                 char sample = 'a';
                 while(!is.eof() && is.peek() != sample)
                   { is.get(); }
                 std::cout << "found " << sample << " at " << is.tellg() << std::endl;

このコードは g++ 4.9 でも clang 3.5 でも動作しません。その null バイトがビットを設定するためbuffer、一致sampleが見つかる前に内部に null バイトが存在するという仮説では機能しません。eof

だから私の質問は次のとおりです:この種のアプローチはまったく避けるべきですか、それともpeekヌルバイトが「必然的に」ストリームの終わりではないことを教える方法がありますか?

4

1 に答える 1

0

コンストラクターを見ると、std::istringstream (2) がstd::string. これには NUL が埋め込まれている可能性がありますが、それがbuffer文字配列またはchar*であるstring場合、暗黙的に呼び出すコンストラクターは、strlenスタイルの ASCIIZ の長さの決定を使用して、ロードするデータの量を計算します。代わりにバッファサイズを明示的に指定する必要があります - 次のように:

std::string str(buffer, bytes);
std::istringstream is(str);

次に、あなたwhile(!is.eof()はひどいです...その問題については何百ものSO Q&Aがあります。ランダムに1つ -ここに。

于 2015-07-21T13:02:52.633 に答える