I see, if you're just writing length delimiters then the most common
convention is to write the size as a varint right in front of the message
itself. Then to read the message you just read the varint prefix first to
find out how many more bytes to read. In Java we have built-in support for
this (writeDelimitedTo and parseDelimitedFrom), but in C++ you have to
write a little bit of boilerplate to do this. Here is some code
showing how to do the parsing for a protobuf delimited this way.
On Mon, Sep 26, 2016 at 4:56 PM, job4charlie <job4char...@gmail.com> wrote:
> hi Adam,
> many thanks for the clarification and for sure I will stick to fix-sized
> type. the whole story was:
> - before I write a message to file, I have to write the length of the
> object first, so I can parse and reconstruct it in memory thru
> SerializeFromArray(char*, size).
> - when I do it, I defined a simple message(containing one single fixed32)
> to keep track of the length, and you know we must make it a fix-sized type
> because we have to parse the length itself thru SerializeFromArray which
> requires a exact correct SIZE!
> - so, in my case, I need to tell the size before I parse my size-tracking
> message before hand in a static way, without breaking my code even
> if I got Google Protocolbuf updated someday in the future.
> - do you know some good practice to do the serialization? I am not sending
> and receiving data via network so I do have to keep track of message length
> myself for every object to be written to the file, and I want both backward
> and forward compatibility!
> thanks and looking forward to hearing form you
> all the best,
> Charlie Chen,
> 在 Adam Cozzette <acozze...@google.com>，2016年9月26日 下午6:43写道：
> Yes, in your case the serialized size will remain the same because you are
> using simple fixed-size fields and always initializing them.
> There are a few things to watch out for, though:
> - If you use proto3 syntax, zero-valued fields will be omitted from the
> serialized output because zero is the default anyway. (But based on your
> example you're using proto2, so that's not an issue.)
> - Varints of course will be variable sized, so you will have to avoid
> those and stick to fixed-size types.
> - If you parse a message that has any unknown fields then those unknown
> fields could take up an arbitrary amount of space when you reserialize the
> On Mon, Sep 26, 2016 at 12:06 PM, <job4char...@gmail.com> wrote:
>> 在 2016年9月26日星期一 UTC-4下午2:57:14，job4c...@gmail.com写道：
>>> Will Google Protocol Buffer ensure this? This is a very important I
>> Notes: My message only uses fixed32 and all fields are
>> initialized(values might vary)
>> Message test_msg
>> optional fixed32 field1 = 1;
>> optional fixed32 field2 = 2;
>> test_msg msg;
>> int size = msg.ByteSize(); // will this be a fixed length even if I
>> upgrade Google Protocol Buffer?
>> 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 protobuf+unsubscr...@googlegroups.com.
>> To post to this group, send email to firstname.lastname@example.org.
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
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 https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.