The Object Management Group (OMG) Interface Definition Language (IDL) is used to describe the interfaces that client objects call and that object implementations provide. An OMG IDL interface definition fully specifies each operation's parameters and provides the information needed to develop client applications that use the interface's operations.
Client applications are written in languages for which mappings from OMG IDL statements have been defined. How an OMG IDL statement is mapped to a client language construct depends on the facilities available in the client language. For example, an OMG IDL exception might be mapped to a structure in a language that has no notion of exception, or to an exception in a language that does.
OMG IDL statements obey the same lexical rules as C++ statements, although new keywords are introduced to support distribution concepts. OMG IDL statements also provide full support for standard C++ preprocessing features and OMG IDL-specific pragmas.
Note:
When using a pragma version statement, be sure to locate it after the corresponding interface definition. The following is an example of proper usage:
module A { interface B { #pragma version B "3.5" void op1(); }; };
The OMG IDL grammar is a subset of ANSI C++ with additional constructs to support the operation invocation mechanism. OMG IDL is a declarative language; it supports C++ syntax for constant, type, and operation declarations; it does not include any algorithmic structures or variables.
For a description of OMG IDL grammar, see Chapter 3 of the Common Object Request Broker: Architecture and Specification Revision 2.4 "OMG IDL Syntax and Semantics."
All OMG IDL grammar is supported, with the exception of the following type declarations and associated literals:
native
Note:
Because CORBA 2.4 states that the native type declaration is intended for use in Object Adapters, not user interfaces, this type is available in the PortableServer module only for clients that support callbacks, that is, joint client/servers.
long double
fixed
Do not use these data types in IDL definitions.
Note:
Support for the long long, unsigned long long, wchar, and wstring data types was added to BEA Tuxedo CORBA in release 8.0.
You can also define your own macros when you are compiling or loading OMG IDL files.
Table 1-1 describes the predefined macros for each platform.
Table 1-1 Predefined Macros
Macro Identifier
Platform on Which the Macro Is Defined
__unix__
Sun Solaris, HP-UX, and IBM AIX
__sun__
Sun Solaris
__hpux__
HP-UX
__aix__
IBM AIX
__win_nt__
Microsoft Windows
Table 1-2 describes constraints for the BEA 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 BEA 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.
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 BEA 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
Workaround
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 BEA 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'.
