1.2 C++ IDL Compiler Constraints

In the following table describes constraints for the Oracle Tuxedo 9.1 C++ IDL compiler and provides information about recommended workarounds.

Table 1-2 C++ IDL Compiler

Constraint Use of wildcarding in OMG IDL context strings produces warnings.
  Description A warning is generated by the C++ IDL compiler when context strings that contain wildcard characters are used in the operation definitions. When you specify a context string in an OMG IDL operation definition, the following warning may be generated: 
void op5() context("*");
                    ^
LIBORBCMD_CAT:131: INFO: ‘*’ is a non-standard
context property.
  Workaround The OMG CORBA specification is ambiguous about whether the first character of a context string must be alphabetic.

This warning is generated to inform you that you are not in compliance with some interpretations of the OMG CORBA specification. If you are intending to specify all strings as context string values, as shown above, the OMG CORBA specification requires a comma-separated list of strings, in which the first character is alphabetic.

Note:

The example shown above is not OMG CORBA compliant, but it is processed by the Oracle Tuxedo software as intended by the user.
Constraint Use of wildcarding in OMG IDL context strings produces warnings.
  Description A warning is generated by the C++ IDL compiler when context strings that contain wildcard characters are used in the operation definitions. When you specify a context string in an OMG IDL operation definition, the following warning may be generated: 
void op5() context("*");
                    ^
LIBORBCMD_CAT:131: INFO: ‘*’ is a non-standard
context property.
  Workround The OMG CORBA specification is ambiguous about whether the first character of a context string must be alphabetic.

This warning is generated to inform you that you are not in compliance with some interpretations of the OMG CORBA specification. If you are intending to specify all strings as context string values, as shown above, the OMG CORBA specification requires a comma-separated list of strings, in which the first character is alphabetic.

Note:

The example shown above is not OMG CORBA compliant, but it is processed by the Oracle Tuxedo software as intended by the user.
Constraint The C++ IDL compiler does not support some data types.
  Description The C++ IDL compiler currently does not support the following data types, which are defined in the CORBA specification version 2.4:
  • native
  • fixed
  • long double
  Workaround Avoid using these data types in IDL definitions.
Constraint Using certain substrings in identifiers may cause incorrect code generation by the C++ IDL compiler.
  Description Using the following substrings in identifiers may cause code to be generated incorrectly and result in errors when the generated code is compiled: 
get_
set_
Impl_
_ptr
_slice
  Workround Avoid the use of these substrings in identifiers.
Constraint Inconsistent behavior in IDL compiler regarding case sensitivity.
  Description According to the CORBA standard, IDL identifiers that differ only in case should be considered colliding and yield a compilation error. There is a current limitation of the Oracle Tuxedo IDL compiler for C++ bindings in that it does not always detect and report such name collisions except for value type. Value type will follow CORBA standard regarding case sensitivity.
  Workaround Avoid using IDL identifiers that differ only in case.
Constraint C++ IDL typedef problem.
  Description The C++ IDL compiler generates code that does not compile when:
  • Defining IDL variables of char or boolean type
  • And the type is aliased multiple times

For example, the generated C++ code from the following IDL code will not compile: 

module X {
        typedef boolean a;
        typedef a b;
        interface Y {
                attribute b Z;
        };
};

C++ compilers report an error that an "operator<<" is ambiguous and that there is no "operator>>" for type char. These errors are produced because of the multiple levels of typedefs; the C++ compiler may not associate the type X::b with CORBA::Boolean because of the intermediate type definition of X::a.

  Workaround Use a single level of indirection when you define char or boolean types. In the IDL example above, the attribute ‘X::Z’ would be defined using either the standard type ‘boolean’ or the user type ‘X::a’, but not the user type ‘X::b’.

Parent topic: OMG IDL Syntax and the C++ IDL Compiler