I didn't saw the sources of protobuf, but using fields count is O(1) too. The overhead is only one more function to decode a submessage.
When all you need to peek are numbers, you can have O(1) access to your > data by simply arranging your proto definition where all float, double, > fixed32 and fixed64 are declared last. > That approach does not need using protobuf's deserialization lib since you > can statically compute the offset of the numbers (preferably by a compiler) > and access the buffer directly. > Well, no. They use varints so it makes the address of fixed iems vary. Moreover any field can be dropped so all addresses will be shifted. The whole field numbers idea was designed to make protocol flexible for future changes as I think. Without that approach field numbers have no sense. And I like that idea. Thanks for the link, but I almost made my own buffers realization and C generator for them. It's easier than building packages for new software under old distribution and using it by a team. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
