Hi Kenton -
Thanks for your help. Obviously defining message types in proto files is
crucial for being able to exchange messages between different languages.
However, as a substitute for Java serialisation having to specify message types
in separate files from the source files seems less
On Thu, Mar 26, 2009 at 6:57 PM, Kenton Varda ken...@google.com wrote:
On Thu, Mar 26, 2009 at 9:28 AM, Jesper jesper.eskil...@gmail.com wrote:
I think so, but I'll double-check. (Wouldn't that have showed up when
libprotobuf.lib was linked into the exe?)
Unfortunately, probably not.
If I understand correctly there is no good way to use proto buffers to
stream different types of messages, right? For example if my stream
has a mix of several messages of type m1 and m2, I will have to device
a scheme outside of proto buffers to separate it into 2 streams and
then pass it
On Mar 27, 1:32 pm, achin...@gmail.com wrote:
If I understand correctly there is no good way to use proto buffers to
stream different types of messages, right? For example if my stream
has a mix of several messages of type m1 and m2, I will have to device
a scheme outside of proto buffers to
Kenton,
I don't suppose there'd ever be a way to mark a set of fields as
mutually exclusive?
-dave
On Mar 27, 8:42 am, Jon Skeet sk...@pobox.com sk...@pobox.com
wrote:
On Mar 27, 1:32 pm, achin...@gmail.com wrote:
If I understand correctly there is no good way to use proto buffers to
achin...@gmail.com writes:
Thanks. Also how do I know the type of the message? One way would be
to check all optional fields (each represent a different type of
message) of the wrapper message and then pick the one which is not
null. Is that the only way?
You can add a (required) field to
On Fri, Mar 27, 2009 at 3:33 AM, Jesper Eskilson jes...@eskilson.se wrote:
(BTW: I created a set of CMake (http://cmake.org) build files for
Protobufs, in case you're interested in not maintaining parallell
Makefiles/project files for Linux/Windows.)
We considered using cmake originally, but
You could treat the protobuf classes as private implemnetation helpers.
Your public interface would have methods like you describe, and internally
they'd just copy the object's state into a protocol buffer and then
serialize it.
On Fri, Mar 27, 2009 at 2:32 AM, Paul Runyan
On Fri, Mar 27, 2009 at 8:08 PM, Kenton Varda ken...@google.com wrote:
On Fri, Mar 27, 2009 at 3:33 AM, Jesper Eskilson jes...@eskilson.se wrote:
(BTW: I created a set of CMake (http://cmake.org) build files for
Protobufs, in case you're interested in not maintaining parallell
On 3/27/2009 3:19 PM, Oleg Smolsky wrote:
Weird... DescriptorPool is destroyed, and so it DescriptorPool::Tables
which frees its 52 outstanding allocations...
OK, I made a silly mistake - I was dumping allocations before static
destructors were executed. Oops.
I've just verified the test and
10 matches
Mail list logo
