In addition to what Henner says, we felt that it wasn't worthwhile to
implement packed encoding for strings or sub-messages because the savings
would be very small. The packed encoding only saves one or two bytes per
element.
On Sun, Jan 17, 2010 at 7:30 PM, Henner Zeller henner.zel...@googlemail.com
wrote:
On Sun, Jan 17, 2010 at 18:59, Atry pop.a...@gmail.com wrote:
When I set [packed = true] on a nested message field, I receive this
error:
[packed = true] can only be specified for repeated primitive fields.
I wonder why it is disallowed.
The reason is to be able to automatically distinguish fields that have
been 'upgraded' from previously non-packed to packed.
This detection can be done because the type on the wire changes for
primitive types but it would not change for non-primitive types.
An example: a non-packed repeated field for a primitive type would be
on the wire something like tag, int-type value tag, int-type
value ...
That would change for packed to something like tag,
length-delimited-type length [value value value ...]
While if it was a length delimited field in the first place, say a
string or a message, that type on the wire length-delimited would
not change, so it is impossible to distinguish just from the raw byte
sequence if this is a length non-packed or a packed repeated field.
Dropping the feature for length delimited fields (for which there is
not much saving to be expected anyway) allows for a safe upgrade path.
The output for packed nested field list as
the below:
The field number and wire type LENGTH_DELIMITED.
Length of all elements.
Length of the first element.
Content of the first element.
Length of the second element.
Content of the second element.
...
Length of the nth element.
Content of the nth element.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.