I'm using a CodedInputStream, based on a FileInputStream in C++ to
read a sequence of size delimited messages (as discussed in recent
posts, I'm building a new CodedInputStream object for each new
message, in order to allow parsing large number of events without
reaching the total bytes limit).
Before reading the size of the message and then its body, I'm calling
the ExpectAtEnd() method to check whether we reached end of stream.
However, it always returns false (which causes my program to report a
warning about junk at end of stream...) Looking at source code, my
understanding is that this method will never return true, unless we
have an explicit limit pushed on the CodedInputStream.
My question is then: how can I safely detect end of file? I guess I
could do something like calling Next() on the underlying
FileInputStream until it returns false (end of file) or a non empty
buffer (and then call BackUp() to re-queue this buffer before creating
the CodedInputStream), but it seems a bit overkill (and probably not
the best thing from a performance point of view...)
Thanks for your advices,
Louis-Marie
I think that detecting the end of file may depend on your underlying
input stream. I have some code that uses the built-in FileInputStream,
and I simply keep trying to read values until I get an error:
bool success = in.ReadVarint32(&size);
if (!success) {
// we are probably at EOF
close();
return;
}
Then my close() method looks like:
assert(input_->GetErrno() == 0);
bool success = input_->Close();
assert(success);
This works for me.
Evan
--
Evan Jones
http://evanjones.ca/