It seems to me, it doesn't work at all.
I got this:
>(Pdb) import ooo
>(Pdb) vals_by_nums =
>req.DESCRIPTOR.fields_by_name['error'].enum_type.values_by_number[req.error]
>(Pdb) options = vals_by_nums.GetOptions()
>(Pdb) options.Extensions[ooo.verbose_enum_value_option]
*** KeyError: 'Extension "v
On 2010-11-09, at 12:01, Christopher Smith wrote:
> On Tue, Nov 9, 2010 at 6:15 AM, Kalki70 wrote:
> On Nov 9, 2:59 am, Kenton Varda wrote:
> > The bigger problem with ASN.1, though, is that it is way over-complicated.
> > It has way too many primitive types. It has options that are not needed
client side:
address_book.SerializeToString(&mystr)
strncpy(buf, mystr.c_str(), strlen(mystr.c_str()));
sendto(socket, buf, )
server side:
recvfrom(socket, buf, )
mystr.assign(buf, strlen(buf));
if (address_book.ParseFromString(mystr) == false)
{
print "deserialization failed"
}
Brad Lira wrote:
address_book.SerializeToString(&mystr)
strncpy(buf, mystr.c_str(), strlen(mystr.c_str()));
strlen will return a shorter length than the real length, due to null
characters. Use mystr.size()
Maybe this method is not the right way to send string across socket.
I tried using
thanks,
yes it was the null character, on the server side when copying buffer
into string, i had add 1 to the
size of the buffer (i guess for the null), then the parsing was ok
with no error.
On Wed, Nov 10, 2010 at 1:42 PM, Evan Jones wrote:
> Brad Lira wrote:
>>
>> address_book.SerializeToSt
On Wed, Nov 10, 2010 at 08:23, Brad Lira wrote:
> client side:
>
> address_book.SerializeToString(&mystr)
> strncpy(buf, mystr.c_str(), strlen(mystr.c_str()));
This is an error - you only copy to the first \0 byte (strlen looks
for a nul-terminated string) -- however, the string contains binary
d
Comment #3 on issue 155 by akollmorgen: Compiler complains with 'error:
extra qualification'
http://code.google.com/p/protobuf/issues/detail?id=155
would be nice to have this fix in a release. the current release 2.3.0
still has this bug.
--
You received this message because you are subsc
On Nov 10, 2010, at 14:13 , Brad Lira wrote:
yes it was the null character, on the server side when copying buffer
into string, i had add 1 to the
size of the buffer (i guess for the null), then the parsing was ok
with no error.
Just adding 1 is still probably not correct. You have similar
in
hmmm, i have to use UDP in my case, TCP is not an option.
On Wed, Nov 10, 2010 at 2:40 PM, Evan Jones wrote:
> On Nov 10, 2010, at 14:13 , Brad Lira wrote:
>>
>> yes it was the null character, on the server side when copying buffer
>> into string, i had add 1 to the
>> size of the buffer (i gues
Comment #4 on issue 155 by ken...@google.com: Compiler complains
with 'error: extra qualification'
http://code.google.com/p/protobuf/issues/detail?id=155
Sorry, we have not done a release in awhile. But we're working on one
now. It's a surprisingly long and tedious process.
--
You recei
On Nov 9, 6:56 pm, maninder batth wrote:
> In typical WS-* webservice, WSDL describes a service interface,
> abstracts from underlying communication protocol and serialization and
> deserialization as well as service implementation platform.
> Where does PB fits in this picture? Is .proto file,
Hi Kenton, all,
When you have a message which contains a string member variable, the
variable is initialized to a default-value.
So you have
::std::string *name_;
static const ::std::string _default_name_;
name_ = &_default_name;
Seems like since _default_name is declared 'const' the microsoft
c
Is this even a legal transformation that the MS compiler is doing
there ? Sounds like a overzealous-optimization compiler bug to me.
Did you try to manually remove the 'const' in the generated proto code
to see if that would fix it ?
On Wed, Nov 10, 2010 at 18:51, Anand Ganesh
wrote:
> Hi Kenton
13 matches
Mail list logo
