message wrapped enums

[Mohamed Koubaa]

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.

Does it make sense for protoc to identify messages that are simply there to wrap enums and provide a lighter api for it?  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

[Feng Xiao]

On Tue, Jul 19, 2016 at 7:38 AM, Mohamed Koubaa <mohamed...@ansys.com> 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 protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[Mohamed Koubaa]

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.

Thanks,

Mohamed Koubaa

Software Developer

Ansys Inc

[Feng Xiao]

On Tue, Jul 19, 2016 at 11:53 AM, Mohamed Koubaa <mohamed...@ansys.com> 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).