This came up because Chromium downstream modifies the lite library in a way that
requires this function, but I'm upstreaming it because based on the comments in
repeated_field.h, this ought to allow resolution of an existing hack.
I don't know enough about the protobuf code to feel confident trying to resolve
this hack myself, so I've merely updated the TODO comments.
When trying to compile the protobuf code as a DLL, and then compile other DLLs
with generated .pb.cc/h files that reference
InternalMetadataWithArena::InternalMetadataWithArena(Arena*), MSVC gives an
"unresolved external symbol" error. This seems to be due to the function being
simultaneously exported and inline. Moving it out-of-line fixes things.
There are other functions exported and inline as well but de-inlining them
doesn't seem to be necessary to get the build working, and I'd rather de-inline
as few functions as possible.
port.h #includes various headers in order to define byteswap functions, but it
currently does so from inside the google::protobuf namespace. This can cause
bizarre symbol conflicts and other build errors as these headers' contents are
then included inside this namespace.
Instead, #include the relevant headers above the namespace declarations.
Updating to the current protobuf version caused the following build errors in
Chromium when using Clang on Windows:
..\..\third_party\protobuf\src\google/protobuf/stubs/fastmem.h(67,43) : error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
if (GOOGLE_PREDICT_FALSE(n_rounded_down == 0)) { // n <= 7
~~~~~~~~~~~~~~~^~~~
The problem is that on Windows, GOOGLE_PREDICT_FALSE is #defined to nothing, so
the code expands to 'if ((n_rounded_down == 0))', which Clang warns about.
Clang would not have warned if the extra parentheses came from the macro,
but in this case they don't because the macro is just dropped.
Fix this by making the macros behave as an identity function instead of just
getting dropped.
This is closer to what these macros look like in stubs/port.h internally.
This compiles with -std=c++11:
message Foo {
map<string, Foo> value = 1;
}
This does not compile:
message Foo {
map<int32, Foo> value = 1;
}
Needs to dig more into the underlying issue.
Feng Xiao
Peter Kasting
Feng Xiao
TeBoring
Jisi Liu
Jisi Liu
Paul Yang
Joshua Haberman
Jan Tattermusch
Jan Tattermusch
Hans Wennborg
Jon Skeet