[protobuf] protobuf maximum value for float, double, int
hello!! What are the maximums ( and minimums) for numeric values that protobuf supports? If so, is there an api to retrieve those limits? I am thinking of something like std::numeric_limits() in c++ standard library. Thanks. lucidbee -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: How Do I Build Just the C++ Libraries?
Thanks for the suggestion Josh! I tried executing the make in the src directory and it completes successfully but I'm not sure I trust the .la files it created, they are only 923 bytes in size. Regards, Doug On Friday, March 17, 2017 at 7:18:47 PM UTC-5, Josh Haberman wrote: > > Try: > > $ cd src && make libprotobuf.la libprotobuf-lite.la > > I can't guarantee it will compile without fork(), but it should avoid > compiling the compiler! > > On Tuesday, March 14, 2017 at 2:01:43 PM UTC-7, Doug Lewis wrote: >> >> I'm going to be using protocol buffers on an embedded system using >> uClinux. I need to build the C++ libraries using the cross-compiler but >> *not* build the protoc compiler, I will compile the proto files on my >> Ubuntu host. If I use the package from git it builds both the protoc >> compiler and the libraries. Due to issues with uClinux, i.e. does not >> support 'fork', the compiler will not build using the full build process >> when configured for the cross-compiler. >> >> How do I build just the C++ libraries? >> >> Thanks, >> Doug >> >> -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
Re: [protobuf] Error/problem using constants! ("Expected top-level statement (e.g. "message")")
The compiler doesn't support that syntax (DataType = DataOther | DataTest).
Maybe a oneof field is what you are looking for; that would look something
like this:
message DataType {
oneof data_type {
DataOther data_other = 1;
DataTest data_test = 2;
}
}
On Mon, Mar 20, 2017 at 10:08 AM, Leonardo Toledo
wrote:
> Hi! I am writing my "file.proto" and when i write a constant the compiler
> give an error called "Expected top-level statement (e.g. "message")" and i
> do not know why! In my "file.proto" i have the follow:
>
> "message Test{
> string str1 = 1;
> DataType data = 2;
> }
>
> DataType = DataOther | DataTest;"
>
> This piece above of code is a part of what i have in my "file.proto" and i
> want define the variable "Datatype" as a constant that can be of 2
> different types, being them, DataOther or DataTest. But when i am
> compiling, the compiler give me the error that i mencioned. Can anyone help
> me please, because i do not know how solve this problem!?
>
> Thanks in advance and i am waiting for some answer,
> Leonardo Toledo
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
[protobuf] Error/problem using constants! ("Expected top-level statement (e.g. "message")")
Hi! I am writing my "file.proto" and when i write a constant the compiler
give an error called "Expected top-level statement (e.g. "message")" and i
do not know why! In my "file.proto" i have the follow:
"message Test{
string str1 = 1;
DataType data = 2;
}
DataType = DataOther | DataTest;"
This piece above of code is a part of what i have in my "file.proto" and i
want define the variable "Datatype" as a constant that can be of 2
different types, being them, DataOther or DataTest. But when i am
compiling, the compiler give me the error that i mencioned. Can anyone help
me please, because i do not know how solve this problem!?
Thanks in advance and i am waiting for some answer,
Leonardo Toledo
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
Re: [protobuf] Re: why protobuf optional field does not take null
In a past life, we used a protoc plugin that just added these setOrClear*
to every builder for each non-repeated field (as well as getOrNull* methods
for every message). The standard generated java code has insertion points
that make this a fairly trivial plugin to write. We also experimented with
adding extra accessors/setters using Guava's Optional (and would probably
use Java 8's Optional today), but that just exploded the API too much.
The generated code is already so voluminous! Adding more and more cruft to
every generated proto wasn't awesome. However, I do agree that the
setOrClear* class of methods was the most useful. Without them, you can't
use method-chaining when building a message where one of the inputs you're
conveying is nullable.
// Kind of stinky:
MyMessage.Builder b = MyMessage.newBuilder()
.setFoo(foo)
.setBar(bar)
.setBaz(baz);
if (frobnitz != null) {
b.setFrobnitz(frobnitz)
}
return b.build();
// Better:
return MyMessage.newBuilder()
.setFoo(foo)
.setBar(bar)
.setBaz(baz)
.setOrClearFrobnitz(frobnitz)
.build();
*Josh Humphries*
jh...@bluegosling.com
On Mon, Mar 20, 2017 at 7:53 AM, Subin Sebastian
wrote:
> 8 years later, still the only solution I have is,
>
> *class MyImprovedClass extends MyClass { // MyClass is protoc generated*
> *public void setOrClearFoo(String value) {*
> *if(value != null) setFoo(value);*
> *else clearFoo();*
> *}*
> *}*
>
> On Tuesday, December 1, 2009 at 7:04:26 AM UTC+5:30, Kenton Varda wrote:
>>
>> I'm still open to the idea of adding setOrClearFoo() methods that clear
>> the value if given null -- but only if it can be shown that this will not
>> significantly increase the size of compiled .class files.
>>
>> On Mon, Nov 30, 2009 at 3:42 PM, Henner Zeller
>> wrote:
>>
>>> Hi,
>>> On Mon, Nov 30, 2009 at 15:16, dp wrote:
>>> > Is this still true? Or is there some way to tell PB that a field can
>>> > potentially have null values?
>>>
>>> No change here.
>>>
>>> Problem is that 'null' and 'cleared' are semantically different things.
>>> Sometimes in the software world they're used to mean the same thing
>>> but protocol buffers shouldn't follow that, because that notion is not
>>> universal if you think platform independently. In C++ for instance,
>>> you won't deal with a 'NULL' string (unlike Java, no pointers, pardon,
>>> references are used there).
>>> Note, that protocol buffers have as well the notion of 'default
>>> values'. So if you set a field to 'null' but meaning to clear it, then
>>> accessing that field will return the default value. This is confusing
>>> at best.
>>>
>>> Given this and the platform independent notion I think it is better to
>>> be explicit and not have 'null' magically meaning clearing a field.
>>>
>>> > If not, any suggestions on how to deal with fields that could
>>> > potentially have null values? (Besides the obvious - don't set them,
>>> > d'oh)
>>> >
>>> > *Asking 'cuz I have a fairly big class (~100 fields) and testing if
>>> > each field is null before setting them in the PB Builder object is
>>> > somewhat of a pain.
>>>
>>> A one-line if (foo != null) b.setFoo(foo) else b.clearFoo(); might be
>>> a bit cluttersome sometimes. OTOH, it is pretty straightforward and
>>> quick to read.
>>>
>>> Maybe you can hack up some dynamic proxy that wraps around the setters
>>> (haven't done Java for some time, probably this only works with
>>> interfaces). Or alternatively you chaneg the higher level logic to
>>> just _not_ set a field instead of setting it to 'null' when it really
>>> means that it doesn't want to set it ...
>>>
>>> -h
>>>
>>> >
>>> > On Oct 29, 10:29 am, Kenton Varda wrote:
>>> >> Protocol buffers has no concept of null. Fields cannot be set to
>>> null. You
>>> >> can *clear* a field, like:
>>> >>
>>> >> builder.clearParamCountry();
>>> >>
>>> >> This sets the field back to its default value (the empty string,
>>> unless you
>>> >> declared some other default). Also, hasParamCountry() will return
>>> false
>>> >> until you set it to something else.
>>> >>
>>> >> But you cannot set any field to null -- this will throw a
>>> >> NullPointerException.
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Oct 29, 2009 at 2:47 AM, micha
>>> wrote:
>>> >>
>>> >> > Hi,
>>> >>
>>> >> > I have a message with a optionl field.
>>> >>
>>> >> > * optional string param_country = 6;
>>> >>
>>> >> > I would like to avoid the to check each attribute if its null or
>>> not,
>>> >> > before setting it to the message.
>>> >>
>>> >> > In the net i found some code fragment of protobuf, that looked to me
>>> >> > that setting this field to null
>>> >>
>>> >> > * .setParamCountry(someNullReference)
>>> >>
>>> >> > makes the Builder to call clearParamCountry().
>>> >>
>>> >> > But I get a NullPoiterException
>>> >
>>> > --
>>> >
>>> > You received this message
Re: [protobuf] Re: why protobuf optional field does not take null
8 years later, still the only solution I have is,
*class MyImprovedClass extends MyClass { // MyClass is protoc generated*
*public void setOrClearFoo(String value) {*
*if(value != null) setFoo(value);*
*else clearFoo();*
*}*
*}*
On Tuesday, December 1, 2009 at 7:04:26 AM UTC+5:30, Kenton Varda wrote:
>
> I'm still open to the idea of adding setOrClearFoo() methods that clear
> the value if given null -- but only if it can be shown that this will not
> significantly increase the size of compiled .class files.
>
> On Mon, Nov 30, 2009 at 3:42 PM, Henner Zeller > wrote:
>
>> Hi,
>> On Mon, Nov 30, 2009 at 15:16, dp
>> wrote:
>> > Is this still true? Or is there some way to tell PB that a field can
>> > potentially have null values?
>>
>> No change here.
>>
>> Problem is that 'null' and 'cleared' are semantically different things.
>> Sometimes in the software world they're used to mean the same thing
>> but protocol buffers shouldn't follow that, because that notion is not
>> universal if you think platform independently. In C++ for instance,
>> you won't deal with a 'NULL' string (unlike Java, no pointers, pardon,
>> references are used there).
>> Note, that protocol buffers have as well the notion of 'default
>> values'. So if you set a field to 'null' but meaning to clear it, then
>> accessing that field will return the default value. This is confusing
>> at best.
>>
>> Given this and the platform independent notion I think it is better to
>> be explicit and not have 'null' magically meaning clearing a field.
>>
>> > If not, any suggestions on how to deal with fields that could
>> > potentially have null values? (Besides the obvious - don't set them,
>> > d'oh)
>> >
>> > *Asking 'cuz I have a fairly big class (~100 fields) and testing if
>> > each field is null before setting them in the PB Builder object is
>> > somewhat of a pain.
>>
>> A one-line if (foo != null) b.setFoo(foo) else b.clearFoo(); might be
>> a bit cluttersome sometimes. OTOH, it is pretty straightforward and
>> quick to read.
>>
>> Maybe you can hack up some dynamic proxy that wraps around the setters
>> (haven't done Java for some time, probably this only works with
>> interfaces). Or alternatively you chaneg the higher level logic to
>> just _not_ set a field instead of setting it to 'null' when it really
>> means that it doesn't want to set it ...
>>
>> -h
>>
>> >
>> > On Oct 29, 10:29 am, Kenton Varda wrote:
>> >> Protocol buffers has no concept of null. Fields cannot be set to
>> null. You
>> >> can *clear* a field, like:
>> >>
>> >> builder.clearParamCountry();
>> >>
>> >> This sets the field back to its default value (the empty string,
>> unless you
>> >> declared some other default). Also, hasParamCountry() will return
>> false
>> >> until you set it to something else.
>> >>
>> >> But you cannot set any field to null -- this will throw a
>> >> NullPointerException.
>> >>
>> >>
>> >>
>> >> On Thu, Oct 29, 2009 at 2:47 AM, micha
>> wrote:
>> >>
>> >> > Hi,
>> >>
>> >> > I have a message with a optionl field.
>> >>
>> >> > * optional string param_country = 6;
>> >>
>> >> > I would like to avoid the to check each attribute if its null or not,
>> >> > before setting it to the message.
>> >>
>> >> > In the net i found some code fragment of protobuf, that looked to me
>> >> > that setting this field to null
>> >>
>> >> > * .setParamCountry(someNullReference)
>> >>
>> >> > makes the Builder to call clearParamCountry().
>> >>
>> >> > But I get a NullPoiterException
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> Groups "Protocol Buffers" group.
>> > To post to this group, send email to prot...@googlegroups.com
>> .
>> > To unsubscribe from this group, send email to
>> protobuf+u...@googlegroups.com .
>> > For more options, visit this group at
>> http://groups.google.com/group/protobuf?hl=en.
>> >
>> >
>> >
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Protocol Buffers" group.
>> To post to this group, send email to prot...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> protobuf+u...@googlegroups.com .
>> For more options, visit this group at
>> http://groups.google.com/group/protobuf?hl=en.
>>
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
