Just a little more info. Apparently if I take out the seekg and only used
one coded stream for the entire file from the example code (since the
example code is just looping over all messages in a vector, there is no
real *NEED* for a byte offset from the header though it IS a feature that I
want in the future), everything is peachy. Using the same concept (only one
zero input stream and codedinputstream for the whole file instead of having
to create new ones for each MyMessage), but putting the seekg in (which
should really just move the the ifstream's position to where it currently
is) doesn't work. Using a new zero input and coded input streams per
MyMessage parse and not using seekg also fails.
1) One CodedInputStream for whole file. No seekg. = WORKS
2) One CodedInputStream for whole file. With seekg (which should seekg to
same byte) = FAILS (message parsing fails for some, parsing ok but invalid
data for others)
3) Multiple CodedInputStream for each MyMessage. No seekg = FAILS (messages
parse properly, invalid data)
4) Multiple CodedInputStream for each MyMessage. With seekg = FAILS
(messages parse properly, invalid data)
So the fact that #2 fails above when #1 works properly is interesting to
me. I'm not sure why that would be. The results from #3 might be expected
depending on implementation of construction of the CodedInputStream. #4 is
basically a combination of the 2 things we know fail, so failing is
Regardless of #1 working above, I would like to be able to not have to read
the complete contents of the file if I know the byte offset and byte size
of the message I want to parse. There must be a way.
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.