On Mar 6, 2011, at 18:45 , ksamdev wrote:
I think I found the source of the problem. The problem is that
CodedInputStream has internal counter of how many bytes are read so
far with the same object.
Ah, right. With the C++ API, the intention is that you will not reuse
the
Hmm, thanks for the advice. It may work fine. Nevertheless, I have to skip
previously read messages in this case every time CodedInputStream is read.
In fact, I faced different problem recently. It turns out I can write
arbitrary long files, even 7GB. No problems.
Unfortunately, reading does
On Mar 7, 2011, at 13:03 , ksamdev wrote:
Hmm, thanks for the advice. It may work fine. Nevertheless, I have
to skip previously read messages in this case every time
CodedInputStream is read.
Not true: Creating a CodedInputStream does not change the position in
the underlying stream. Your
Comment #9 on issue 248 by jonny.de...@googlemail.com: protobuf will not
compile without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
So now I am not sure whether there is a way to build 2.4.0a without pthread
dependency. I would like to use protobuf in a
Comment #10 on issue 248 by ken...@google.com: protobuf will not compile
without thread library
http://code.google.com/p/protobuf/issues/detail?id=248
You will need to modify the protobuf code slightly, but it should be easy.
Find the places that use pthread (there aren't many of them)
I have a composite message, meaning Message C is composed of Message
A and Message B.
Message C
{
required Message A = 1;
required Message B = 2;
}
This composite message C I have serialized to disk ( say output.dat).
At a later stage in the code, the values of (say) Message A are
changed
