Down-integrate from internal code base.
This commit is contained in:
parent
be20ae0b69
commit
9104da3261
104
CHANGES.txt
104
CHANGES.txt
@ -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++
|
||||
|
@ -97,7 +97,7 @@ public class MapFieldLite<K, V> {
|
||||
if (a == b) {
|
||||
return true;
|
||||
}
|
||||
if (a.size() != a.size()) {
|
||||
if (a.size() != b.size()) {
|
||||
return false;
|
||||
}
|
||||
for (Map.Entry<K, V> entry : a.entrySet()) {
|
||||
|
@ -260,6 +260,13 @@ public class MapTest extends TestCase {
|
||||
assertFalse(m1.equals(m2));
|
||||
// Don't check m1.hashCode() != m2.hashCode() because it's not guaranteed
|
||||
// to be different.
|
||||
|
||||
// Regression test for b/18549190: if a map is a subset of the other map,
|
||||
// equals() should return false.
|
||||
b2.getMutableInt32ToInt32Field().remove(1);
|
||||
m2 = b2.build();
|
||||
assertFalse(m1.equals(m2));
|
||||
assertFalse(m2.equals(m1));
|
||||
}
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user