|
|
|
@ -1,3 +1,107 @@ |
|
|
|
|
2014-12-01 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 impelmented. |
|
|
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
2014-10-20 version 2.6.1: |
|
|
|
|
|
|
|
|
|
C++ |
|
|
|
|