Prior to XBinder 2.2.2, the value for an enumerated type was represented using OSUINT16. From version 2.2.2 onward, the generated enum type is now used. Either -compat 221 or else -noenumvars will restore the old behavior. Depending on the C/C++ compiler, and the options used with it, one or the other approach may be more space efficient.
An XSD string-based type that is restricted by enumeration is represented by a C enum typedef which enumerates all of the identifiers that can be used in the type. (This is the only case where enumeration facets affect the corresponding C representation.)
The general mapping is as follows:
XSD type:
<xsd:simpleType name="TypeName"> <restriction base="xsd:string"> <xsd:enumeration value="enum1"/> <xsd:enumeration value="enum2"/> ... <xsd:enumeration value="enumN"/> </xsd:restriction> </xsd:simpleType>
Table 4.1. Generated C code
normal | with -noenumvars |
---|---|
//Fields will be declared as TypeName (an enum type) //TypeName_ENUM is declared to help with upgrading from //v2.2.1 or earlier. typedef enum { TypeName_enum1 = 0, TypeName_enum2 = 1, ... TypeName_enumN = N - 1, } TypeName; typedef TypeName TypeName_ENUM; //deprecated |
//Fields will be declared as TypeName (OSUTIN16). //TypeName_ENUM exists only to define useful names. typedef enum { TypeName_enum1 = 0, TypeName_enum2 = 1, ... TypeName_enumN = N - 1, } TypeName_ENUM; typedef OSUINT16 TypeName; |
Table 4.2. Generated C++ code
normal | with -noenumvars |
---|---|
//The enum type is used for the value class TypeName : public OSRTBaseType { public: enum Enum { enum1 = 0, enum2 = 1, ... enumN = N - 1, } ; Enum value; ... } ; |
//The enum type just defines useful names. class TypeName : public OSRTBaseType { public: enum Enum { enum1 = 0, enum2 = 1, ... enumN = N - 1, } ; OSUINT16 value; ... } ; |
Note that for C, TypeName is used on the enumerated identifiers as a namespace mechanism in order to prevent name clashes if two or more enumerated types use the same identifier names. In this case, the type name may only be a partial fragment of the full name to keep the names shorter. This is not a problem in C++ as the class provides a namespace for the enumeration constants defined within (for example, enum1 would be referenced as TypeName::enum1 outside the class).
In XSD, the rules for naming enumerated identifiers are more liberal than in the C/C++ programming language. For example, enumerated identifiers can start with numbers or punctuation marks. The logic to transform the XSD enumeration names to C/C++ form makes use of the following rules to ensure the names are valid C/C++ names:
If all items are numeric, no symbolic identifiers are generated. The user is expected to work with the items in numeric form.
If an enumeration identifier consists of whitespace (for example, enumeration value=" "), the special name BLANK is used.
Other special names are used for other single punctuation mark identifiers (for example, '+' = PLUS).
If after applying these rules, the name still has a non-alphabetic start character, the character 'x' is prepended.
All invalid C/C++ identifier characters are replaced with underscores (_) within the name.