I think if you have to work with C types then you will need to provide both
a char* and an integer length. That Python error makes it sound like the
Python code is probably trying to parse beyond the end of the serialized
message.
On Wed, Oct 14, 2020 at 3:55 PM Randy Nuss wrote:
> I am building
I am building a C++ library with protobuf messages for consumption by a
Python program. The issue is SerializeToString() takes std::string, but
only c_types (like char*) can be exported by the dll, which results in
numerical zeros being recognized as string terminators and truncating the
Parse
Makes sense, thanks.
Alternatively, there seem to be Java options that we could define? (since
we're doing Java)
Guy
Op woensdag 14 oktober 2020 om 09:48:12 UTC+2 schreef marc.g...@gmail.com:
> "custom options" exist, but frankly they don't do much unless you have
> custom code generation tha
"custom options" exist, but frankly they don't do much unless you have
custom code generation that is going to emit something useful from them,
and that "something" itself does something useful at runtime - which may
itself be tricky between runtimes/platforms.
Does "add a comment" suffice?
On We
Hi,
Being new to protocol buffers and gRPC, I am looking for a good way to add
metadata "annotations" to the contract description.
In particular, we are adding transaction context propagation across gRPC
calls. We would like to mark some RPCs (or services) as "transactional" -
meaning that the
You're absolutely right! Thanks!
BR
Adam Cozzette escreveu no dia terça, 13/10/2020 à(s)
18:07:
> Serialized protocol buffers don't contain any metadata to indicate what
> type they are, so you have to have some other mechanism to know what the
> type is. I would guess that your .proto file pr
