3D PLM Enterprise Architecture

The CAA V5 IDL

The CAA V5 IDL (Interface Definition Language) is the language you will use to write your interfaces. It is closely derived from the OMG IDL of CORBA and allows the declaration of how your interfaces will behave regardless how and using which language they will be implemented.

The CAA V5 IDL uses the following object types (the definitions are those of CORBA if they exist):

1. The interfaces: an interface is a set of possible operations that a client may request of an object. It is converted into C++ as a class that contains no data members, but only methods.
2. The types: a type is an identifiable entity with an associated predicate (a single-argument mathematical function with a boolean result) defined over values. Types can be basic types, such as integer or float, and constructed type such as structure or interface.
3. The operations: an operation is an identifiable entity that denotes a service that can be requested

Some lexical conventions are required by IDL to accommodate mapping for several programming languages:

• Two objects can not have their identifiers which differ only by casing since upper-case and lower-case characters are treated as the same character
• A object identifier must be consistently spelled as declared, with respect to case
• The same identifier can not be used for two objects, such as an interface and a constant
• IDL keywords are not allowed as identifiers
• Operators, such as =, +, and so forth can not be overloaded
• An identifier can not begin using the _ character (underscore). This prevents from colliding with C++ names in the generated code. Check that the C++ code you write does not contain such _ characters.

Remind also that any object declaration must be located before using it.

Below is the BNF grammar of all the constructed types available with the CAA V5 IDL.

[Top]

Types

IDL provides C-language like declarations that associate an identifier with a type. A type can be a basic type, such as an integer or a float, that is an object whose internal structure is known, or a type can be a constructed type, such as a structure, or even an interface, or finally a type can be a template type.

Basic types are:

• Integer types, declared as short, long, or unsigned short and unsigned long if the value is always positive.
• Floating-point types, declared as float and double
• Character type, declared as char
• Boolean type, declared as boolean. It can only take one of the values TRUE and FALSE
• Any type, declared as any. It permits the specification of values that can express any IDL type.

These types are mapped to C++ types as follows:

Constructed types can be constructed from the following basic types:

• Enumeration declared as enum is a finite ordered list of identifiers

[Top]

Interface

The interface gathers a list of operations available for requests on an object. The interface is equivalent to the public part of a class in C++, or to a list in CATIA. An interface is declared as follows:

// CAA V5 IDL
#pragma ID A "DCE:00020400-0000-0000-C000000000000046"
interface A
{
...
};

and is converted into C++ as:

// C++
class A : public CATBaseUnknown
{
  CATDeclareInterface;
  public :
  ...
};

The interfaces support inheritance as in C++. For example, the interface B is declared as inheriting from the interface A:

// CAA V5 IDL
#pragma ID A "DCE:00020400-0000-0000-C000000000000046"
#pragma DUAL A;
interface A
{
...
};
#pragma ID B "DCE:00020400-0000-0000-C000000000000047"
#pragma DUAL B;
interface B : A {
...
};

is converted into C++ as follows:

// C++
class A : public CATIABase
{
  CATDeclareInterface;
  public :
  ...
};
class B : public A
{
  CATDeclareInterface;
  public :
  ...
};

According to CAA V5 Object Model rules, the multi-inheritance is not allowed.

It is possible to use the forward declaration to declare an interface before it is fully declared:

// CAA V5 IDL
interface A;
#pragma ID B "DCE:00020400-0000-0000-C000000000000047"
#pragma DUAL B;
interface B : A {
...
};
#pragma ID A "DCE:00020400-0000-0000-C000000000000046"
#pragma DUAL A;
interface A
{
...
};

is translated as follows:

// C++
class A;
class B : public A
{
  public :
  ...
};
class A : public CATIABase {
  public :
  ...
};

[Top]

Automation Library or Typelib

To provide type information at run time for the scripts, Microsoft COM offers the type library, which does not exist with CORBA. This makes it possible for the interpreted language to access the methods by means of the virtual function table of the object and to ensure run time type checking like C++ run time does. In addition, it is much faster than the late binding. The type library is a compiled version of a set of IDL files. It contains the description of all the interfaces, all the method prototypes, properties, and all the parameters they require along with their types.

If you want to take advantage of Automation capabilities, you need to declare the interfaces in a type library source file, suffixed by tplib. This is an example of such a file:

#pragma REPID INFITF "DCE:14f197b2-0771-11d1-a5b100a0c9575177"
#pragma REPBEGIN INFITF

#pragma REPREQ PreReqTypeLib

#include "CATIApplication.idl"
#include "CATIPageSetup.idl"
#include "CATIWindow.idl"

#pragma REPEND INFITF

where:

• INFITF is the type library name
• CATIApplication.idl, CATIPageSetup.idl and CATIWindow.idl the files containing the interfaces
• REPID, REPBEGIN and REPEND are keywords to declare respectively the type library name and its GUID, the beginning and the end of the interfaces to include in the type library
• REPREQ declares the prerequisite type libraries.

The IDL compiler builds the run time type library from such a source file and stores it in a shared library with UNIX or a DLL with Windows.

[Top]

Enumeration

The enumeration consists in a finite ordered list of identifiers. For example:

// CAA V5 IDL
enum color {cyan, yellow, magenta, black};

is converted into C++ as:

// C++
enum color {cyan, yellow, magenta, black};

Find the difference!

[Top]

Alias (typedef)

You can create aliases for any data types. The typedef keyword associates a name with a data type. You should associate a GUID to each created alias, as follows:

// CAA V5 IDL
#pragma ID Name "DCE:00020500-0000-0000-C000000000000046"
typedef Name String

[Top]

String

A string is mapped to the C++ char *

[Top]

Operation and Operation Arguments

An operation maps to a C++ function with the same name as the operation.

The objects that can be declared as operation arguments are the types, the constants, the attributes, and the exceptions.

The parameters passed as operation arguments must be declared along with their passing modes belonging to one of the following:

• in: the parameter is passed from the calling application to the called object
• out: the parameter is passed from the called object to the calling application
• inout: the parameter is passed from the calling application to the called object and is passed back from the called object to the calling application when the called method returns.

Depending on the passing mode chosen, the signature generated will change. The following table shows the basic argument types and the passing result:

You should pay attention when choosing the passing mode. Mapping in arguments leaves the caller deal with memory allocation and deallocation for these arguments. Mapping inout and out arguments is more difficult. For variable length arguments, the callee must allocate part or all of the required storage. For fixed length arguments, the caller allocation is preferable. In addition, all storage areas for variable length arguments allocated by the callee must be deallocated.

[Top]

The IDL Compiler

The IDL compiler allows you to generate C++ source code for your interface classes from IDL sources which describe the interfaces. The IDL compiler runs in three steps:

1. The first step uses the C++ preprocessor to preprocess the IDL sources and to generate an expanded IDL source. The #include and the #define statements are expanded.
2. The second step generates the C++ header file for the class. The C++ #include statements are inserted at the right place. The included files must be generated before by the IDL compiler. The #define statements remain expanded.
3. The third step generates the C++ header file for the TIE class.

The following figure shows these three IDL compiler steps

[Top]

How to Invoke the IDL Compiler

The IDL compiler is included into the building tool mkmk. Your C++ abstract classes are then automatically created when you use mkmk.

[Top]

Openness of the IDL Compiler

You may want to use the IDL compiler with the following restrictions or specificities:

• A class that you use in one of your interfaces has no interface declared using IDL, but is declared using C++. Suppose the CATIXX interface needs the CATNeighbor class which has no IDL interface. You just need to include interface CATNeighbor in CATIXX.idl, compile it and add #include "CATNeighbor.h" in the generated CATIXX.h file.

  

• You want to use a constructed type, like a structure, a union or a sequence (sequence is the IDL term for list). You declare it in the IDL file, but the compiler generates the corresponding C++ code only for structures and sequences, but not for union. You need then to provide the code for unions. This is a temporary restriction.

  

[Top]

About the IDL Compiler Behavior and Error Messages

The IDL compiler has the following behavior or generates error messages in the following cases:

• The IDL file name MUST be identical to the class name followed by a dot and the suffix idl. Example: CATIXX.idl where the class name is CATIXX
• The error messages of the C++ preprocessor are not taken into account and this often generates errors in the following steps.
• The compiler stops in the second step when the first error is encountered
• The errors detected by the syntactical and lexical analyzer issues always the message syntax error. It provides the file and the number of the line where the error is found
• Some parts of the compiler are not yet implemented. They can be recognized by means of the character string NYI
• Some of the DS coding rules are checked. They can be recognized by means of the character string DSLIM
• The IDL language does not allow for overloading, and does not allow for default value for method parameters. DO NOT USE THEM
• The IDL language is not case sensitive. Never use names or identifier that match regardless the case sensitivity. This apply to class names, method names and other names within the common scope limitations
• The compiler does not generate code for the exceptions and for the contexts (context is an IDL term).

[Top]

In Short

The CAA V5 IDL (Interface Definition Language) is dedicated to create programming language independent interfaces that you can use from both a compiled language such as C++, and scripting languages such as Visual Basic and JScript with Windows, and Basic Script with UNIX.

The IDL compiler inntegrated with mkmk generates both the C++ abstract classes used as interfaces for C++, and the type library to access these interfaces from a scripting languages.

[Top]

References

History

Copyright © 2000, Dassault Systèmes. All rights reserved.