you make this change without updating millions of lines of
> existing C++ code that uses protobuf enums?
>
> On Fri, Aug 20, 2010 at 11:12 AM, alopecoid wrote:
>>
>> Hi,
>>
>> This post is about the fact that protobuf enum values use C++ scoping
>> rules, mean
Hi,
This post is about the fact that protobuf enum values use C++ scoping
rules, meaning that, unlike in Java, enum values are siblings of their
type, not children of it.
Say I have the following contrived message:
message MyMessage {
enum Foo {
FIRST = 0;
SECOND = 1;
BOT
Hi,
Using the Java API, when attempting to parse a text-formatted protobuf
message that contains adjacent strings that are meant to be
concatenated, such as in the following contrived example:
name:"John Smith"
profession:"mailman"
description:
"all these strings "
"are concate
> That makes no sense. If the bytes were the same, how would deserializing
> them be able to produce unequal messages?
Yes, I guess if we can rely on the canonical ordering of the fields,
that should be enough.
> If possible, I would recommend designing your application such that it only
> requ
> Given that the serialized bytes have to be able to *deserialize* back
> to the original messages, surely if those original messages aren't
> equal, the serialized forms would have to be different too - assuming
> we're talking about the same message type
But, as in my example, that doesn't seem
Hi,
Can serialized messages be used reliably as keys?
In other words, is it guaranteed that...
- Two equal messages will always generate equal byte sequences?
(Are fields always written in the same order?)
- Two unequal messages will always generate unequal byte sequences?
(Are tag identifiers
Hi Kenton,
Thanks for your reply.
> You can't continue to use a Builder after calling build(). Even if we made
> it so you could, it would be building an entirely new object, not reusing
> the old one. We can't make it reuse the old one because that would break
> the immutability guarantee of
Hi,
I haven't actually used the Java protobuf API, but it seems to me from
the quick occasional glance that this isn't entirely true. I mean,
specifically in response to the code snippet posted in the original
message, I would possibly:
1. Reuse the Builder object by calling its clear() method.
