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.com<protobuf%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<protobuf%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.
