So many trailing underscores

Can somebody explain to me the trailing underscore usage in the out-of-the-box IDL files? It shows at the end of “module dds_” and at the end of every struct name in the IDL. It also shows up at the end of every field in those structs. I believe this last usage can be traced to the Google coding standard, which says class fields need to use trailing underscores. While it’s debatable whether the IDL specifies “fields” or “properties”, I especially don’t understand the first two usages, module and struct.

The trailing underscore on struct names ensures that the full name is guaranteed to be a valid C++ struct name. Without the underscore depending on how the use names the message it might not be. E.g. a user might use a message which collides with a keyword. The same holds true for the fields.

It would certainly be possible to state in the docs “don’t use any C++ keywords as message/field names”. But that would not be sufficient for all generated code. It would need to be “don’t use any keywords from any programming language” which is much more difficult to follow. (An alternative would be that the language specific generator adds trailing underscores on demand in cases where the name would collide with a keyword in that language.)

Since the generated DDS API is only internally within the vendor specific typesupport and rmw implementation we didn’t spend more time on this. For the future in my opinion ROS 2 needs to be able to interface with existing DDS types defined not by ROS. So there needs to be either a mapping from one DDS type to the ROS-specific DDS type or the ROS-specific DDS type needs to be able to use a custom (not following our convention of <pkgname>::dds_::<msgname>_ with <fieldname>_) mapping. But neither of these topics have been address so far (and are not scheduled on the roadmap atm).

For the dds_ module I don’t recall if there was a rational why it was chosen.

1 Like