Using the 'tk_foreign' TypeCode

TypeCodes can be used to partially describe types that cannot be described in IDL (for example, a FILE type in C, or a specific class type in C++). The SOM-unique extension tk_foreign is used for this purpose. A tk_foreign TypeCode contains three parameters:

• The name of the type,
  
• An implementation context string, and
  
• A length.

The implementation context string can be used to carry an arbitrarily long description that identifies the context where the foreign type can be used and understood. If the length of the type is also known, it can be provided with the length parameter. If the length is not known or is not constant, it should be specified as zero. If the length is not specified, it will default to the size of a pointer. A tk_foreign TypeCode can also have alignment information specified, just like any other TypeCode.

Using the following steps causes the SOM Compiler to create a foreign TypeCode in the Interface Repository:

• Define the foreign type as a typedef SOMFOREIGN in the IDL source file.

• Use the #pragma modifier statement to supply the additional information for the TypeCode as modifiers. The implementation context information is supplied using the "impctx" modifier.

• Compile the IDL file using the -u option to place the information in the Interface Repository.

For example:

typedef SOMFOREIGN Point;#pragma modifier Point: impctx="C++ Point class",length=12,align=4;

If a foreign type is used to define instance data, structs, unions, attributes, or methods in an IDL source file, it is your responsibility to ensure that the implementation and/or usage bindings contain an appropriate definition of the type that will satisfy your compiler. You can use the passthru statement in your IDL file to supply this definition. However, it is not recommended that you expose foreign data in attributes, methods, or any of the public types, if this can be avoided, because there is no guarantee that appropriate usage binding information can be provided for all languages. If you know that all users of the class will be using the same implementation language that your class uses, you may be able to disregard this recommendation.