While I've provided operators, I haven't yet provided the method equivalents. It's not clear to me that
they're actually a good idea, while we're really targeting C# developers who definitely *can* use the user-defined operators.
This is a follow up CL for e9abc404df,
which breaks build when UNICODE macro is defined.
protoc has explicitly called MBCS version of APIs / funcsions
rather than UTF-16 (wchar_t) version of them regardless of
UNICODE macro definition (and it indeed works as expected).
Hence it makes sense to call GetModuleFileNameA explicitly.
Additionally, change it to return the value passed, and make it generic with a class constraint.
A separate method doesn't have the class constraint, for more unusual scenarios.
The issue occurs when the template type deduction results in NodeType
being const.
Shortened version of compile error:
no matching function for call to 'operator new'
new (p) NodeType(std::forward<Args>(args)...);
candidate function not viable: no known conversion from 'const
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> > *' to 'void *' for 2nd argument; take the
address of the argument with &
inline __attribute__ ((__visibility__("hidden"), __always_inline__))
void* operator new (std::size_t, void* __p) noexcept {return __p;}
- Fix nupec paths
- Remove an obsolete part of the JSON build
- Add documentation and tests to reflection extension methods, and improve implementations
This requires .NET 4.5, and there are a few compatibility changes required around reflection.
Creating a PR from this to see how our CI systems handle it. Will want to add more documentation,
validation and probably tests before merging.
This is in aid of issue #590.
I think Jan was actually suggesting keeping both, but that feels redundant to me. The test diff is misleading here IMO, because I wouldn't expect real code using reflection to use several accessors one after another like this, unless it was within a loop. Evidence to the contrary would be welcome :)
This change also incidentally goes part way to fixing the issue of the JSON formatter not writing out the fields in field number order - with this change, it does except for oneofs, which we can fix in a follow-up change.
I haven't actually added a test with a message with fields deliberately out of order - I'm happy to do so though. It feels like it would make sense to be in google/src/protobuf, but it's not entirely clear what the rules of engagement are for adding new messages there. (unittest_proto3.proto?)
Jon Skeet
Jon Skeet
Yohei Yukawa
Jan Tattermusch
Jan Tattermusch
Tom Hughes
Paul Yang
Xiao Hang
teboring
Feng Xiao
LitingLin
Yue Zhang
Bo Yang
Nico Weber