Re: [protobuf] message - group?
hmm this is a slight problem. I am iterating over the nested messages and then generating a message/group code. I don't have reference to the specific field 2010/4/29 Kenton Varda ken...@google.com A single message type can be used as both a message and as a group, so there is no way to tell which it is from the Descriptor. You have to have the FieldDescriptor in the containing message. On Thu, Apr 29, 2010 at 1:36 PM, adamdms adam.kwintkiew...@gmail.comwrote: how to check whether the current message (Descriptor *) is a group? -- 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.
Re: [protobuf] message - group?
They have different wire type (2; 3 and 4). They are stored in different ways and because of that they have a little bit different code inside parsing/serializing methods. 2010/4/29 Kenton Varda ken...@google.com Why do you need to generate different code for the two? All the official code generators generate exactly the same code for message classes whether they be nested messages or groups. Version 1 of protocol buffers generated different classes and it proved to be an enormous pain. On Thu, Apr 29, 2010 at 2:04 PM, Adam Kwintkiewicz adam.kwintkiew...@gmail.com wrote: hmm this is a slight problem. I am iterating over the nested messages and then generating a message/group code. I don't have reference to the specific field 2010/4/29 Kenton Varda ken...@google.com A single message type can be used as both a message and as a group, so there is no way to tell which it is from the Descriptor. You have to have the FieldDescriptor in the containing message. On Thu, Apr 29, 2010 at 1:36 PM, adamdms adam.kwintkiew...@gmail.comwrote: how to check whether the current message (Descriptor *) is a group? -- 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.
Re: [protobuf] packed repeated fields / extensions
Thank you
2010/4/26 Jason Hsueh jas...@google.com
The packed option is specified in the FieldOptions proto:
const FieldDescriptor* f = ...;
if (f-options().packed()) {
// field is packed
}
On Mon, Apr 26, 2010 at 2:29 PM, adamdms adam.kwintkiew...@gmail.comwrote:
how to check whether the field / expansion (FieldDescriptor *) is
repeated with packed = true option?
--
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.
Re: [protobuf] int32 negative numbers
... for a negative number, the resulting varint is *always ten bytes long ...* I didn't saw that part. Thanx 2010/3/21 Evan Jones ev...@mit.edu On Mar 21, 2010, at 8:46 , adamdms wrote: I am wonder why int32 field (with negative value) has 10 bytes? 10 - field No 2, wire type 0 FD FF FF FF FF FF FF FF FF 01 - field value = -3 Can someone explain it to me? See: http://code.google.com/apis/protocolbuffers/docs/encoding.html#types Hope this helps, Evan -- Evan Jones http://evanjones.ca/ -- 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.
Re: [protobuf] int32 negative numbers
Thank you for your reply. Yes you are right. I just wondered why int32 consists of 10 bits, rather than a maximum of 5 (in the case of large or negative numbers). Adam 2010/3/21 Henner Zeller henner.zel...@googlemail.com On Sun, Mar 21, 2010 at 08:05, Adam Kwintkiewicz adam.kwintkiew...@gmail.com wrote: ... for a negative number, the resulting varint is always ten bytes long ... Reason for that is the varint encoding: it only encodes the bits that are set in an integer. For small positive values that results in a more compact format. However, negative values always have the very first bit set (the sign bit), so these values end up to be longer. If you have values that are centering around zero but whose absolute values usually don't use the full range, then the 'sint32' would be probably a better encoding for you: it is done in 'zigzag'-encoding that uses short encoding for small absolute values and longer for larger absolute values. If your numbers are big or pretty random, then you might consider fixed32. Note however, that changing the type from int32 to sint32 or fixed32 are not compatible - so if you've already data stored that way or have running services that talk RPC in that way, you need an upgrade path; probably adding a new field with the new encoding, setting it in parallel for some time (until all other users are gone). If you have stored data the old way and don't want to recode than you've to forever test - on reading - if the 'old' field exists and take that value. -h I didn't saw that part. Thanx 2010/3/21 Evan Jones ev...@mit.edu On Mar 21, 2010, at 8:46 , adamdms wrote: I am wonder why int32 field (with negative value) has 10 bytes? 10 - field No 2, wire type 0 FD FF FF FF FF FF FF FF FF 01 - field value = -3 Can someone explain it to me? See: http://code.google.com/apis/protocolbuffers/docs/encoding.html#types Hope this helps, Evan -- Evan Jones http://evanjones.ca/ -- 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.
Re: [protobuf] strange encoding
I see my mistakes. Thanks
On 1 Mar 2010 08:44, Kenton Varda ken...@google.com wrote:
On Sun, Feb 28, 2010 at 3:47 AM, adamdms adam.kwintkiew...@gmail.com
wrote:
I created (from tu...
This is field number 1, wire type 2 (length-delimited).
Remember that the thing you are encoding is an AddressBook, not a Person.
message AddressBook {
repeated Person person = 1;
}
So the first byte is the tag for a person in the AddressBook.
2E - 0|010 1110 - 46 (but first person has ID = 1)
This is the length of the Person message.
0A - 0|000 1010 - wire type 0 (variant, but that field is string, it
should be type = 2); f...
Now we're actually in the Person, so this is the name field. Note that
fields are ordered by field number, so name always comes *before* id.
04 - length is ok
41 - A
64 - d
61 - a
6D - m
...
Can someone explain t...
--
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.
