[protobuf] Reading different message types from the same input

2010-01-07 Thread Nigel Pickard
I read various messages on this subject in the message board, but couldn't really find what I was looking for. Here is what I'd like to do: 1. I have messages of type Animal, Vegetable and Mineral. 2. I want to send these 3 dissimilar objects of Animal, Vegetable and Mineral to a file or output s

Re: [protobuf] Reading different message types from the same input

2010-01-07 Thread Kenton Varda
On Thu, Jan 7, 2010 at 12:42 PM, Nigel Pickard wrote: > I read various messages on this subject in the message board, but > couldn't really find what I was looking for. Here is what I'd like to > do: > > 1. I have messages of type Animal, Vegetable and Mineral. > 2. I want to send these 3 dissimi

[protobuf] Issue 150 in protobuf: src/Makefile relies on $^ which is not understood by FreeBSD make.

2010-01-07 Thread protobuf
Status: Accepted Owner: ken...@google.com Labels: Type-Defect Priority-Medium New issue 150 by ken...@google.com: src/Makefile relies on $^ which is not understood by FreeBSD make. http://code.google.com/p/protobuf/issues/detail?id=150 FreeBSD's default "make" does not seem to understand the

Re: [protobuf] Reading different message types from the same input

2010-01-07 Thread Kenton Varda
On Thu, Jan 7, 2010 at 1:35 PM, Graham Cox wrote: > On 7 Jan 2010, at 21:14, Kenton Varda wrote: > >> Use the wrapper message technique combined with extensions: >> > > One thing to be careful with this method is not double-allocating extension > numbers, or does the compiler take" care of that

[protobuf] Errors during make install.

2010-01-07 Thread mancha
I get these error during make install. make and make check suceeded earlier. Can you please advise how to resolve this. Thanks, Madhav. /usr/bin/ld: /usr/local/lib/libz.a(deflate.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/l

[protobuf] Is there a way to pass C string without triggering construction of string object in C++?

2010-01-07 Thread Vlad
There is an overhead in creating string object from the message. It is more faster to obtain direct pointer to the data and length of it. inline bool has_name() const; inline void clear_name(); static const int kNameFieldNumber = 1; inline void set_name(const ::std::string& value); inlin

Re: [protobuf] Errors during make install.

2010-01-07 Thread Kenton Varda
It looks like you don't have a shared version of libz installed. As a result you'll need to compile libprotobuf as a static library only, which you can do with: configure --disable-shared However, it's odd that the tests worked. It's also odd that your libz.a is in /usr/local/lib rather than /

Re: [protobuf] Is there a way to pass C string without triggering construction of string object in C++?

2010-01-07 Thread Kenton Varda
Protobuf messages store strings in std::string objects. Sorry, there's no way around that. The problem with direct pointers is that you have ownership issues -- what if the data pointed to is modified or free()d while the message still exists? Making a defensive copy is not that expensive and av

Re: [protobuf] Is there a way to pass C string without triggering construction of string object in C++?

2010-01-07 Thread Evan Jones
On Jan 7, 2010, at 17:41 , Vlad wrote: inline const ::std::string& name() const; //problem here need creation of string -> very slow! This doesn't create a string, it just returns a reference to the string already in the protocol buffer object. If you do: const char* c_string = protobuff

Re: [protobuf] 2.3.0 release candidate #2

2010-01-07 Thread David Yu
Just noticed that the Builders from the generated java code doesn't protect against empty string (only does null protect). Same goes with ByteString. On Thu, Jan 7, 2010 at 2:44 PM, Kenton Varda wrote: > I've put up a second release candidate in the same place: > https://groups.google.com/gro

Re: [protobuf] 2.3.0 release candidate #2

2010-01-07 Thread Kenton Varda
On Thu, Jan 7, 2010 at 3:34 PM, David Yu wrote: > Just noticed that the Builders from the generated java code doesn't protect > against empty string (only does null protect). Same goes with ByteString. > What do you mean? Empty strings are perfectly valid field values. > > On Thu, Jan 7, 201

Re: [protobuf] 2.3.0 release candidate #2

2010-01-07 Thread David Yu
When writing to the CodedOutputStream, it will be written as 0 length delimited (0)bytes. The Builder's setFoo(String foo) fails to protect it. On Fri, Jan 8, 2010 at 7:50 AM, Kenton Varda wrote: > On Thu, Jan 7, 2010 at 3:34 PM, David Yu wrote: > >> Just noticed that the Builders from the gene

Re: [protobuf] 2.3.0 release candidate #2

2010-01-07 Thread Kenton Varda
On Thu, Jan 7, 2010 at 3:53 PM, David Yu wrote: > When writing to the CodedOutputStream, it will be written as 0 length > delimited (0)bytes. > That is correct. > The Builder's setFoo(String foo) fails to protect it. What is it supposed to protect? > > > On Fri, Jan 8, 2010 at 7:50 AM, Ken

Re: [protobuf] 2.3.0 release candidate #2

2010-01-07 Thread David Yu
Oh ok, didn't think it was normal to write delimited data with 0 length and no data. But I guess that is how the empty string is passed around. Thanks. On Fri, Jan 8, 2010 at 8:00 AM, Kenton Varda wrote: > On Thu, Jan 7, 2010 at 3:53 PM, David Yu wrote: > >> When writing to the CodedOutputStrea

[protobuf] Re: Issue 150 in protobuf: src/Makefile relies on $^ which is not understood by FreeBSD make.

2010-01-07 Thread protobuf
Updates: Status: Fixed Labels: FixedIn-2.3.0 Comment #1 on issue 150 by ken...@google.com: src/Makefile relies on $^ which is not understood by FreeBSD make. http://code.google.com/p/protobuf/issues/detail?id=150 (No comment was entered for this change.) -- You received this