[protobuf] Re: Why to reinvent the wheel ?

2010-11-09 Thread multijon
As a side note, the company I worked at used ASN.1 for five years to encode all of its product's communication messages (Using PER encoding), with what was supposed to be a highly optimized implementation of ASN.1. One of my last projects in the company was to try and convert our encoding method (

Re: Error with has_field method in C++, protobuf 2.1.0

2009-08-12 Thread multijon
Final update: The problem was indeed with the message generation and serialization in C#. The class generator was called without the optional 'detectMissing' flag, and so did not create nullable fields. This seems to me as an unwanted default behaviour. Jon On Aug 12, 10:26 am

Re: Error with has_field method in C++, protobuf 2.1.0

2009-08-12 Thread multijon
ocol Buffers are arbitrary byte arrays and may contain > NULs, so this won't work.  You must either store the message in a > std::string or you must keep track of the length of the message separately. > > > > On Tue, Aug 11, 2009 at 9:01 AM, multijon wrote: > > > Hi, >

Re: Error with has_field method in C++, protobuf 2.1.0

2009-08-11 Thread multijon
oes the C# implementation. Does that sound like a realistic explanation? Jon On Aug 11, 7:36 pm, Peter Keen wrote: > If I understand the docs correctly has_* will return false if the > value is the same as the default, which in the case of numbers > defaults to 0. > > --Pete >

Re: Error with has_field method in C++, protobuf 2.1.0

2009-08-11 Thread multijon
ther store the message in a > std::string or you must keep track of the length of the message separately. > > > > On Tue, Aug 11, 2009 at 9:01 AM, multijon wrote: > > > Hi, > > > I'm seeing a strange behaviour of the protobuf library in the > > following si

Error with has_field method in C++, protobuf 2.1.0

2009-08-11 Thread multijon
Hi, I'm seeing a strange behaviour of the protobuf library in the following situation: I have a message which contains an optional field uint32 'uploadLimit'. I have created and serialized a message containing the value 0 in this field. When reading this message in Python and C#, I have the val

Re: null-value default

2009-05-25 Thread multijon
Scratch that. I realized that using the has_field method I can check whether the field was initialized, which is equivalent to None. Jon On May 25, 4:46 pm, multijon wrote: > Hi, > > I'm starting to use Protocol Buffers as a replacement for a > proprietary data serializati

null-value default

2009-05-25 Thread multijon
Hi, I'm starting to use Protocol Buffers as a replacement for a proprietary data serialization solution using Python, and was wondering whether there is a way of providing a NULL (or a Python 'None') default value to a field. Thanks, Jon --~--~-~--~~~---~-