Consider the use of the IDL4 @optional annotation instead of unions
-
Key: OARIS3-69
-
Status: open
-
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
-
Summary:
The IDL4 language introduced the @optonal annotation that indicates that a structure member is optional. This is also supported by DDS-XTYPES. For example:
// radians per second typedef double azimuth_rate_type; // radians per second typedef double elevation_rate_type; // meters per second typedef double range_rate_type; struct polar_velocity_type { // The rate of change in azimuth corresponding to the velocity azimuth_rate_type azimuth_rate; // The rate of change in elevation corresponding to the velocity. // Optional as some sensors provide no elevation information @optional elevation_rate_type elevation_rate; // The rate of change in range corresponding to the velocity. // Optional as some sensors provide no range information // (e.g. most passive sensors) @optional range_rate_type range_rate; };
The OARIS IDL does not take advantage of this. Instead, it uses an older pre-IDL4 idiom using an extra "union" type. For example:
// radians per second typedef double azimuth_rate_type; // radians per second typedef double elevation_rate_type; // meters per second typedef double range_rate_type; // a simple union type, to represent an optional value union polar_velocity_elevation_rate_type switch (boolean) { // the value when present case TRUE : elevation_rate_type value; }; // a simple union type, to represent an optional value union polar_velocity_range_rate_type switch (boolean) { // the value when present case TRUE : range_rate_type value; }; // Velocity defined in a polar reference frame as a described by a coordinate // specification object struct polar_velocity_type { // The rate of change in azimuth corresponding to the velocity azimuth_rate_type azimuth_rate; // The rate of change in elevation corresponding to the velocity. // Optional as some sensors provide no elevation information polar_velocity_elevation_rate_type elevation_rate; // The rate of change in range corresponding to the velocity. // Optional as some sensors provide no range information // (e.g. most passive sensors) polar_velocity_range_rate_type range_rate; };
The extra union types result in more code generated to serialize and deserialize the data, increasing the size of the binary and decreasing performance.
Moreover, the use of the @optional annotation allows for a more natural and optimized language mapping. For example, the recent IDL to C++ mapping maps optional members to the standard std::optional which is more natural for a C++ programmer.
-
Reported: OARIS 3.0a1 — Thu, 18 Jul 2024 03:58 GMT
-
Updated: Thu, 18 Jul 2024 03:58 GMT