I am aware that Cord support landed, which is very welcome. But it is quite
limited since only singular bytes fields can be Cord. It is also limited in
that the Cord fields will not alias the input, unless that input is also a
Cord.
As an example of why this is limiting, consider a message that minimally
frames other messages, where it is desirable to parse the inner messages
one at a time, with aliasing/without copying, and where it is undesirable
or impossible to copy the input. This would be done like:
message outer {
repeated bytes inner = 1 [ctype=CORD];
}
... but this is impossible today, since Cord fields cannot be repeated,
despite the tantalizing fact that RepeatedField is specialized for Cord.
Ideally, what users really want here is repeated string_view, not Cord,
because Cord has so much baggage (cordz etc) and often the inputs are
string_view anyway, and constructing the initial Cord is just a waste of
time in that case.
Today I support a codebase that refuses to use upstream protobuf because
some grouchy, unreformed C programmers claim that it copies too much and is
therefore too slow. The irritating part of the situation is: they are
right. So I maintain a complete, private protobuf codec internally that is
more efficient overall, but which never gets the benefit of upstream
performance and feature work like tables, epsinput, etc.
Other than mentioning that I want it, I am not sure if there is anything I
can do to bring string_view support to the open-source side of the project.
If there is anything I can do, please mention it.
-jwb
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/protobuf/25c92047-f58b-428b-8fa6-f93eaca40cacn%40googlegroups.com.
