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
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
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
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
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
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
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 /
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
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
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
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
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
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
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
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
15 matches
Mail list logo