ic
User's Guide
Version 4.3.1

Chapters

• Using the IC Compiler
  • Top of chapter
  • Introduction
  • Compilation of IDL Files
• OMG IDL
  • Top of chapter
  • OMG IDL - Overview
• IC Protocol
  • Top of chapter
  • Introduction
  • Language mappings and IDL operations
  • IC Protocol
  • Gen_server Protocol
  • Erlang Distribution Protocol
• Using the Plain Erlang Back-end
  • Top of chapter
  • Introduction
  • Compiling the Code
  • Writing the Implementation File
  • An Example
• Using the Erlang Generic Server Back-end
  • Top of chapter
  • Introduction
  • Compiling the Code
  • Writing the Implementation File
  • An Example
• IDL to C mapping
  • Top of chapter
  • Introduction
  • C Mapping Characteristics
  • Basic OMG IDL Types
  • Constructed OMG IDL Types
  • OMG IDL Constants
  • OMG IDL Operations
  • Exceptions
  • Access to Attributes
  • Summary of Argument/Result Passing for the C-client
  • Supported Memory Allocation Functions
  • Special Memory Deallocation Functions
  • Exception Access Functions
  • Special Types
  • A Mapping Example
• The C Client Back-end
  • Top of chapter
  • Introduction
  • Generated Stub Files
  • C Interface Functions
  • Generating, Compiling and Linking
  • An Example
• The C Server Back-end
  • Top of chapter
  • Introduction
  • Generated Stub Files
  • C Skeleton Functions
  • The Server Loop
  • Generating, Compiling and Linking
  • An Example
• CORBA_Environment C Structure
  • Top of chapter
  • C Structure
  • The CORBA Compatibility Part
  • The External Part
  • The Internal Part
  • Creating and Initiating the CORBA_Environment Structure
  • Setting System Exceptions
• IDL to Java language Mapping
  • Top of chapter
  • Introduction
  • Specialties in the Mapping
  • Basic OMG IDL Types
  • Constructed OMG IDL Types
  • Mapping for Constants
  • Invocations of Operations
  • Exceptions
  • Access to Attributes
  • Summary of Argument/Result Passing for Java
  • Communication Toolbox
  • The Package com.ericsson.otp.ic
  • The Term Class
  • Stub File Types
  • Client Stub Initialization, Methods Exported
  • Server Skeleton Initialization, Server Stub Implementation, Methods Exported
  • A Mapping Example
  • Running the Compiled Code

2 OMG IDL

2.1  OMG IDL - Overview

The purpose of OMG IDL, Interface Definition Language, mapping is to act as translator between platforms and languages. An IDL specification is supposed to describe data types, object types etc.

Since the C and Java IC backends only supports a subset of the IDL types supported by the other backends, the mapping is divided into different parts. For more information about IDL to Erlang mapping, i.e., CORBA, plain Erlang and generic Erlang Server, see the Orber User's Guide. How to use the plain Erlang and generic Erlang Server is found in this User's Guide.

Reserved Compiler Names and Keywords

The use of some names is strongly discouraged due to ambiguities. However, the use of some names is prohibited when using the Erlang mapping , as they are strictly reserved for IC.

IC reserves all identifiers starting with OE_ and oe_ for internal use.

Note also, that an identifier in IDL can contain alphabetic, digits and underscore characters, but the first character must be alphabetic.

Using underscores in IDL names can lead to ambiguities due to the name mapping described above. It is advisable to avoid the use of underscores in identifiers.

The OMG defines a set of reserved words, shown below, for use as keywords. These may not be used as, for example, identifiers.

The keywords listed above must be written exactly as shown. Any usage of identifiers that collide with a keyword is illegal. For example, long is a valid keyword; Long and LONG are illegal as keywords and identifiers. But, since the OMG must be able to expand the IDL grammar, it is possible to use Escaped Identifiers. For example, it is not unlikely that native have been used in IDL-specifications as identifiers. One option is to change all occurrences to myNative. Usually, it is necessary to change programming language code that depends upon that IDL as well. Since Escaped Identifiers just disable type checking (i.e. if it is a reserved word or not) and leaves everything else unchanged, it is only necessary to update the IDL-specification. To escape an identifier, simply prefix it with _. The following IDL-code is illegal:

typedef string native;
interface i {
   void foo(in native Arg);
   };
};
      

With Escaped Identifiers the code will look like:

typedef string _native;
interface i {
   void foo(in _native Arg);
   };
};