Hi,
I was wondering whether enums in protobuf are also extendable.
If, for example, I currently have a proto definition consisting of:
enum testEnum
{
a = 1;
b = 2;
}
and would like to add in the future c=3 - would that be possible?
Thanks,
--
Jon
--
You received this message
message info
{
required string username =1;
required string pwd =2;
required string pin =3;
required string imei =4;
required string imsi
See the discussion trail:
http://groups.google.com/group/protobuf/browse_thread/thread/36152305f0f21a66
-john
On Jun 15, 3:30 am, Jonathan Zion Mozes multi...@gmail.com wrote:
Hi,
I was wondering whether enums in protobuf are also extendable.
If, for example, I currently have a proto
Comrades,
I have a class I'd like to submit to the protocol buffer code base.
It's a class called GeneratedMessageParser, and it parses messages
from generic parameters. Here's why:
I have a glass called MessageTranceiverM extends Message. This class
needs to call the parseFrom() method of
Try this:
M prototype = M.getDefaultInstance();
// later on
M instance = prototype.newBuilderForType().mergeFrom(data).build();
On Tue, Jun 15, 2010 at 1:30 PM, Miguel Muñoz swingguy1...@yahoo.comwrote:
Comrades,
I have a class I'd like to submit to the protocol buffer code base.
It's a
Kenton,
You try it!
You can't say M.getDefaultInstanceForType() for the same reason you can't say
M.parseFrom(buffer). You can't call any of the methods from M, because it's
type information has been erased at runtime. That's why I wrote my parser class.
-- Miguel
On Jun 15, 2010, at
Sorry, I should have been a bit clearer.
You've defined a new interface called GeneratedMessageParser, and when
someone instantiates a generic class which needs to parse things, they need
to pass in an instance of your interface to do the parsing.
I'm saying that they can just pass in the
A bool is only allowed to be zero or one. The C++ standard states that the
behavior of a program when a bool has any other value is undefined.
Therefore, the behavior you are seeing -- where branches for if(x) and
if(!x) are both taken -- is actually standard-compliant compiler behavior
given
