On Wed, Apr 29, 2015 at 6:21 AM, Nikolay Mladenov <
nikolay.mlade...@gmail.com> wrote:
> I am also evaluating proto2 vs proto3 and even though it seems proto3
> should be the way to go I really miss the has_** functionality in proto3.
>
> It seems the following proto pattern may be a workaround:
>
> message M{
> oneof optional_value{
> int32 value = 1;
> }
> }
>
> It does generate value(), set_value(), clear_value() and has_value()
> methods (C++) but unfortunately the has_value is private.
> Is there a reason such a useful and short method is declared private (it
> implementation only uses public functionality as well)
>
You can use "optoinal_value_case()" to check which oneof is set.
>
>
>
>
> On Wednesday, February 11, 2015 at 3:55:03 PM UTC-5, Alfred Kwan wrote:
>>
>> Thanks for pointing me to "oneof". I gave it a try and I have two
>> questions:
>> 1) I see the has_() being generated for all the fields inside oneof. Is
>> this kind of has_() function here to stay throughout subsequent V3 releases?
>> 2) Since oneof does not allow a repeated field in both V2/3, is there
>> pro/cons in case I create one extra layer of structure i.e.:
>> message manyMsg{ // workaround: wrap the repeating message
>> repeated oneMsg = 1;
>> }
>> message unionMsg{
>> oneof testOneof{
>> manyMsg msg = 1; // doesn't allow repeated
>> uint32 foo = 2;
>> }
>> }
>>
>>
>>
>> On Sunday, February 8, 2015 at 11:01:04 PM UTC-5, Feng Xiao wrote:
>>>
>>> The union types are obsoleted by oneof:
>>> https://developers.google.com/protocol-buffers/docs/proto#oneof
>>>
>>> On Sat, Feb 7, 2015 at 4:53 AM, Alfred Kwan <alfr...@gmail.com> wrote:
>>>
>>>> To implement the has_boo() in 3.0 implies one boolean per each truly
>>>> optional field, which means additional maintenance is now required, e.g.
>>>> matching naming scheme for the pool together with the optional struct, also
>>>> should we group all booleans together or should they sit right next to the
>>>> to corresponding optional structures...
>>>>
>>>> With the uncertainty of how "any" replaces "extensions" plus the
>>>> removal of has_boo(), it seems like new adopters (I'm one of them) should
>>>> pick V2 over 3.0.
>>>>
>>>> On Wednesday, January 28, 2015 at 3:10:39 PM UTC-5, Feng Xiao wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wed Jan 28 2015 at 12:06:21 PM Troy Lee <lee...@gmail.com> wrote:
>>>>>
>>>>>> Feng,
>>>>>>
>>>>>> Version 3 removes presence logic.
>>>>>> How do we exam whether a field is exist or not?
>>>>>>
>>>>> This is no possible for singular primitive fields. For singular
>>>>> message fields, the has methods will still be generated. Basically with
>>>>> proto3 you'll need to write your code without depending on these dropped
>>>>> features. It's believed that most users don't use the field presence logic
>>>>> much and for those who need this feature adding a bool field is an easy
>>>>> workaround.
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> troylee
>>>>>>
>>>>>> Feng Xiao於 2014年12月11日星期四 UTC+8下午12時51分01秒寫道：
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I just published protobuf v3.0.0-alpha-1 on our github site:
>>>>>>> https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1
>>>>>>>
>>>>>>> This is the first alpha release of protobuf v3.0.0. In protobuf
>>>>>>> v3.0.0, we will add a new protobuf language version (aka proto3) and
>>>>>>> support a wider range of programming languages (to name a few: ruby,
>>>>>>> php,
>>>>>>> node.js, objective-c). This alpha version contains C++ and Java
>>>>>>> implementation with partial proto3 support (see below for details). In
>>>>>>> future releases we will add support for more programming languages and
>>>>>>> implement the full proto3 feature set. Besides proto3, this alpha
>>>>>>> version
>>>>>>> also includes two other new features: map fields and arena allocation.
>>>>>>> They
>>>>>>> are implemented for both proto3 and the old protobuf language version
>>>>>>> (aka
>>>>>>> proto2).
>>>>>>>
>>>>>>> We are currently working on the documentation of these new features
>>>>>>> and when it's ready it will be updated to our protobuf developer
>>>>>>> guide <https://developers.google.com/protocol-buffers/docs/overview>.
>>>>>>> For the time being if you have any questions regarding proto3 or other
>>>>>>> new
>>>>>>> features, please post your question in the discussion group.
>>>>>>>
>>>>>>> CHANGS
>>>>>>> =======
>>>>>>> Version 3.0.0-alpha-1 (C++/Java):
>>>>>>>
>>>>>>> General
>>>>>>> * Introduced Protocol Buffers language version 3 (aka proto3).
>>>>>>>
>>>>>>> When protobuf was initially opensourced it implemented Protocol
>>>>>>> Buffers
>>>>>>> language version 2 (aka proto2), which is why the version number
>>>>>>> started from v2.0.0. From v3.0.0, a new language version
>>>>>>> (proto3) is
>>>>>>> introduced while the old version (proto2) will continue to be
>>>>>>> supported.
>>>>>>>
>>>>>>> The main intent of introducing proto3 is to clean up protobuf
>>>>>>> before
>>>>>>> pushing the language as the foundation of Google's new API
>>>>>>> platform.
>>>>>>> In proto3, the language is simplified, both for ease of use and
>>>>>>> to
>>>>>>> make it available in a wider range of programming languages. At
>>>>>>> the
>>>>>>> same time a few features are added to better support common
>>>>>>> idioms
>>>>>>> found in APIs.
>>>>>>>
>>>>>>> The following are the main new features in language version 3:
>>>>>>>
>>>>>>> 1. Removal of field presence logic for primitive value fields,
>>>>>>> removal
>>>>>>> of required fields, and removal of default values. This
>>>>>>> makes proto3
>>>>>>> significantly easier to implement with open struct
>>>>>>> representations,
>>>>>>> as in languages like Android Java, Objective C, or Go.
>>>>>>> 2. Removal of unknown fields.
>>>>>>> 3. Removal of extensions, which are instead replaced by a new
>>>>>>> standard
>>>>>>> type called Any.
>>>>>>> 4. Fix semantics for unknown enum values.
>>>>>>> 5. Addition of maps.
>>>>>>> 6. Addition of a small set of standard types for
>>>>>>> representation of time,
>>>>>>> dynamic data, etc.
>>>>>>> 7. A well-defined encoding in JSON as an alternative to binary
>>>>>>> proto
>>>>>>> encoding.
>>>>>>>
>>>>>>> This release (v3.0.0-alpha-1) includes partial proto3 support
>>>>>>> for C++ and
>>>>>>> Java. Items 6 (well-known types) and 7 (JSON format) in the
>>>>>>> above feature
>>>>>>> list are not implemented.
>>>>>>>
>>>>>>> A new notion "syntax" is introduced to specify whether a .proto
>>>>>>> file
>>>>>>> uses proto2 or proto3:
>>>>>>>
>>>>>>> // foo.proto
>>>>>>> syntax = "proto3";
>>>>>>> message Bar {...}
>>>>>>>
>>>>>>> If omitted, the protocol compiler will generate a warning and
>>>>>>> "proto2" will
>>>>>>> be used as the default. This warning will be turned into an
>>>>>>> error in a
>>>>>>> future release.
>>>>>>>
>>>>>>> We recommend that new Protocol Buffers users use proto3.
>>>>>>> However, we do not
>>>>>>> generally recommend that existing users migrate from proto2 from
>>>>>>> proto3 due
>>>>>>> to API incompatibility, and we will continue to support proto2
>>>>>>> for a long
>>>>>>> time.
>>>>>>>
>>>>>>> * Added support for map fields (implemented in C++/Java for both
>>>>>>> proto2 and
>>>>>>> proto3).
>>>>>>>
>>>>>>> Map fields can be declared using the following syntax:
>>>>>>>
>>>>>>> message Foo {
>>>>>>> map<string, string> values = 1;
>>>>>>> }
>>>>>>>
>>>>>>> Data of a map field will be stored in memory as an unordered map
>>>>>>> and it
>>>>>>> can be accessed through generated accessors.
>>>>>>>
>>>>>>> C++
>>>>>>> * Added arena allocation support (for both proto2 and proto3).
>>>>>>>
>>>>>>> Profiling shows memory allocation and deallocation constitutes a
>>>>>>> significant
>>>>>>> fraction of CPU-time spent in protobuf code and arena allocation
>>>>>>> is a
>>>>>>> technique introduced to reduce this cost. With arena allocation,
>>>>>>> new
>>>>>>> objects will be allocated from a large piece of preallocated
>>>>>>> memory and
>>>>>>> deallocation of these objects is almost free. Early adoption
>>>>>>> shows 20% to
>>>>>>> 50% improvement in some Google binaries.
>>>>>>>
>>>>>>> To enable arena support, add the following option to your .proto
>>>>>>> file:
>>>>>>>
>>>>>>> option cc_enable_arenas = true;
>>>>>>>
>>>>>>> Protocol compiler will generate additional code to make the
>>>>>>> generated
>>>>>>> message classes work with arenas. This does not change the
>>>>>>> existing API
>>>>>>> of protobuf messages and does not affect wire format. Your
>>>>>>> existing code
>>>>>>> should continue to work after adding this option. In the future
>>>>>>> we will
>>>>>>> make this option enabled by default.
>>>>>>>
>>>>>>> To actually take advantage of arena allocation, you need to use
>>>>>>> the arena
>>>>>>> APIs when creating messages. A quick example of using the arena
>>>>>>> API:
>>>>>>>
>>>>>>> {
>>>>>>> google::protobuf::Arena arena;
>>>>>>> // Allocate a protobuf message in the arena.
>>>>>>> MyMessage* message = Arena::CreateMessage<MyMessage
>>>>>>> >(&arena);
>>>>>>> // All submessages will be allocated in the same arena.
>>>>>>> if (!message->ParseFromString(data)) {
>>>>>>> // Deal with malformed input data.
>>>>>>> }
>>>>>>> // Must not delete the message here. It will be deleted
>>>>>>> automatically
>>>>>>> // when the arena is destroyed.
>>>>>>> }
>>>>>>>
>>>>>>> Currently arena does not work with map fields. Enabling arena in
>>>>>>> a .proto
>>>>>>> file containing map fields will result in compile errors in the
>>>>>>> generated
>>>>>>> code. This will be addressed in a future release.
>>>>>>> =======
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Feng
>>>>>>>
>>>>>> --
>>>>>> 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+u...@googlegroups.com.
>>>>>> To post to this group, send email to prot...@googlegroups.com.
>>>>>> Visit this group at http://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+u...@googlegroups.com.
>>>> To post to this group, send email to prot...@googlegroups.com.
>>>> Visit this group at http://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 http://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 http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
