On Tue, Jul 19, 2016 at 11:53 AM, Mohamed Koubaa <[email protected]> wrote:
> Hi Feng, > > I didn't think about the use case of passing empty messages. No, I have > not measured the binary size impact. Actually I was more annoyed by my IDE > suggesting all of the inherited message methods when I really only wanted > to see the enum values. > > If a binary size impact is measurable and poses a problem for us we could > suggest some workarounds - but I don't see this in the near future. > > A possibility is annotating the messages in the proto file as 'enum > wrappers' for protoc to deal with them differently. Alternatively, enum > messages could be annotated with a namespace. > Protoc support a plugin framework where you can write your own code-generator. It should be fairly easy to write a plugin to generate only the enums in a namespace in your case. More info here: https://github.com/google/protobuf/blob/master/src/google/protobuf/compiler/plugin.h#L35 Some teams inside Google are already using such a plugin to generate code for their too-large proto enums (an enum with thousands of values). > > Thanks, > Mohamed Koubaa > Software Developer > Ansys Inc > > On Tue, Jul 19, 2016 at 2:26 PM, Feng Xiao <[email protected]> wrote: > >> >> >> On Tue, Jul 19, 2016 at 7:38 AM, Mohamed Koubaa <[email protected] >> > wrote: >> >>> Hello, >>> >>> In my cpp proto3 project I am using enums that are wrapped in messages >>> to avoid namespace collisions. See for example: >>> >>> message Physics { >>> enum Enum { >>> STRUCTURAL = 0; >>> THERMAL = 1; >>> } >>> } >>> >>> In c++ I can refer to it by Physics::STRUCTURAL which is great. >>> >>> In this case, the Physics message does not have any fields. It derives >>> from google::protobuf::Message or MessageLite and has some generated >>> methods that are not relevant. In a project with several thousand enums, >>> this could create binary bloat when compiled. >>> >> Have you measured the binary size impact of these generated classes? >> >> >>> >>> Does it make sense for protoc to identify messages that are simply there >>> to wrap enums and provide a lighter api for it? >>> >> Even for an empty message, protoc has to generate the >> parsing/serialization methods because passing empty messages in RPC is a >> valid use case and the empty message may be extended to be not empty later. >> >> >> >>> Or more generally to identify messages that do not have fields and >>> derive from something even smaller than MessageLite? >>> >>> Thanks, >>> Mohamed Koubaa >>> Software Developer >>> Ansys Inc >>> >>> -- >>> 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 post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/protobuf. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
