enum with duplicate values

3 posts / 0 new
Log in or register to post comments
Last post
Fri, 02/15/2013 - 06:23
#1
jschroettle
Offline
Last seen: 2 years 10 months ago
Joined: 02/15/2013
Posts: 20
enum with duplicate values

Hello there,

I have problems with enums containing duplicate values in IDL files.
This was accepted in version 4.5 but now generates a compilation error in FooPlugin.cxx in version 5.0
Sample enum to reproduce:

enum eLogLevel
{
LOG_DATA = 0, LOG_DEBUG = 0,
LOG_CONTROL = 1, LOG_INFO = 1,
LOG_WARNING = 2,
LOG_ERROR = 3, LOG_MINOR = 3,
LOG_CRITICAL = 4, LOG_MAJOR = 4
};

This generates errors 'duplicate case labels' because the deserialization now contains a switch statement.

Removing the duplicate values is not an option as they are used in multiple other files.

Any ideas how to solve this 4.5 / 5.0 incompatibility?

Regards

Josef

Top
Mon, 02/18/2013 - 09:21
rip
rip's picture
Offline
Last seen: 3 days 18 hours ago
Joined: 04/06/2012
Posts: 324

Hi,

Multiply defined values are disallowed by the XTypes specification as it would break the "is-assignable-from" handling:

ENUMERATION_TYPE if an only if:

  • Any constants that have the same name in T1 and T2

    also have the same value, and any constants that have the same value in T1 and T2 also have the same namea.

  • T1.extensibility == T2.extensibility

The (a) footnote: 

Design rationale (non-normative): Certain Data Representations may preserve only the value (e.g., CDR) or only the name (e.g., XML). To preserve representation independence, the Type System requires both to remain stable.

Because CDR doesn't keep both the name and the value, the receiving side would not know if you meant LOG_DATA or LOG_DEBUG if it received a "0" in the CDR stream.  This loss of precision is anethema to structured data, sorry.

Pre-XTypes versions of the DDS-specific version of IDL were silent on the concept of user-defined valuations for enumerations.  Some of RTI's code generator versions did support it, but it was an extension to, not something inline with, the then-current specification. 

All of the ways that I can think of, require you to change your IDL on both 4.5* and 5.0.0 systems.  Can't recommend hacking around with the serialization/deserialization methods as that would be a maintenance nightmare. 

Regards,

rip

Top
Tue, 02/19/2013 - 22:32
Gerardo Pardo
Gerardo Pardo's picture
Offline
Last seen: 4 weeks 1 day ago
Joined: 06/02/2010
Posts: 601

Hi Josef,

Rip is right in that if you want to have your types be extensible/evolvable then you cannot have duplicate values in your enumeration.  However it is still possible to have the old behavior and use duplicate values in an enumeration if you explicitly tag the enumeration to have "final" extensibility.

Prior to version 5.0.0 RTI Connext DDS did not support extentible types so we were not checking for this. Starting with version 5.0.0 we introduced partial support for the OMG DDS-XTYPES specification and this changed the default code generated to dis-allow it.

This is how you annotate your enumerated type to have FINAL_EXTENSIBILITY:

enum eLogLevel
{
    LOG_DATA = 0, LOG_DEBUG = 0,
    LOG_CONTROL = 1, LOG_INFO = 1,
    LOG_WARNING = 2,
    LOG_ERROR = 3, LOG_MINOR = 3,
    LOG_CRITICAL = 4, LOG_MAJOR = 4 
}; //@Extensibility FINAL_EXTENSIBILITY

The annotation  //@Extensibility FINAL_EXTENSIBILITY tells rtiddsgen that the enumeration will not be extended and teh code generated does not have to enforce the uniqueness of the values assigned to the tags. If you do not specify this annotation the defaul extensibility  ( //@Extensibility EXTENSIBLE_EXTENSIBILITY) is used and the code generated will not allow duplicated values as you noted.

Gerardo

Top