OMG IDL Syntax and the C++ IDL Compiler

 

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.

 

---

OMG IDL Compiler Extensions

The IDL compiler defines preprocessor macros specific to the platform. All macros predefined by the preprocessor that you are using can be used in the OMG IDL file, in addition to the user-defined macros. 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, Tru64 UNIX, and IBM AIX
__osf1__	Tru64 UNIX
__sun__	Sun Solaris
__hpux__	HP-UX
__aix__	IBM AIX
__win_nt__	Microsoft Windows 2000 and NT

 

Note: The following platforms will not be supported when BEA Tuxedo 8.0 is initially released to customers, however, they will be certified and supported after the release:

• IBM AIX

• Microsoft Windows NT

  To find out when the support for these platforms becomes official, contact BEA Customer Support. The contact Customer Support, go to http://www.beasys.com/support/ on the Internet and click on Contact Customer Support.

 

---

C++ IDL Compiler Constraints

Table 1-2 describes constraints for the BEA Tuxedo 8.0 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.
	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'.