Did anyone get a chance to look at this request?
On Wednesday, December 17, 2014 3:54:12 PM UTC-8, Arjun Satish wrote: > > Hey guys, > > Thanks for all the hard work! > > I have a question regarding the decision to drop support for default > values. Fields which are set to their default values are not serialized. I > noticed that in the new code (3.0.0-alpha-1 for Java), this condition > still holds true. But the default values used are the standard ones (0 for > int64/int32 etc) and cannot be specified in the .proto file. In some of my > code, I had reasons to use non-zero default values (-1 for some integers, > 1024 for some others, 3.14 for some doubles etc). Using the old protocol > buffers, this was trivial to implement. This was a great feature as we > could save atleast 2 bytes for every "untouched" field (which comes in > handy when we persist the data :-)). > > Is there any way we can retain specification of default values in the > .proto files and using them in the generated encoders/decoders? > > Thanks very much! > > Looking forward to the 3.0 release! > > Best, > Arjun Satish > > > On Wednesday, December 10, 2014 8:51:01 PM UTC-8, Feng Xiao wrote: >> >> 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.
