The official implementations do NOT accept multiple encodings, but it would theoretically be possible for them to do so. This wasn't implemented mainly because code size bloat is a big problem and accepting multiple encodings would increase code size -- even users who don't even use [packed=true] would be affected, since they'd still need to generate code which accepts it. That said, I'm up for reconsidering this decision.
On Sun, May 31, 2009 at 10:37 PM, Joshua Haberman <jhaber...@gmail.com>wrote: > > I was reading the documentation about packed encoding [0] (haven't dug > into the code), and was wondering if parsers are expected to be able > to read packed encoding whether or not [packed=true] is specified. > Unlike any other option (AFAIK), [packed=true] actually changes the > bytes that encoders will output. It seems like decoders must be > prepared to read either packed or non-packed encoding of repeated > fields. Is this the case? The alternative (that [packed=true] is not > interoperable with [packed=false]) seems undesirable. > > Josh > > [0] > http://code.google.com/apis/protocolbuffers/docs/encoding.html#optional > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@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 -~----------~----~----~----~------~----~------~--~---
