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)
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 <[email protected]> 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 <[email protected]> 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 [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> 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 [email protected].
>>> To post to this group, send email to [email protected].
>>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
