7.5 - The Generated Code

Table of Contents

• 7.5.1 Enumerations
• 7.5.2 Data Types
• 7.5.3 Objects and Interactions
• 7.5.4 Project Files and Makefiles
• 7.5.5 Attributes and Types that Cannot be Decoded and Generated

The VR-Link Code Generator generates files containing all the enumerations, data types, net types, and classes that implement the publishing and subscribing of the objects and interactions contained within the FOM definition file.

7.5.1 Enumerations

An enumerations file is generated from the enumerated data types in the OMT or XML file. The file is named FomNameEnum.h, where FomName is the name of the FOM for the definition file you loaded. The size of the enumeration over the network is determined based on the type of definition file loaded, as follows:

• If you load an XML file, the size is determined by its representation in the XML file.
• If you load an OMT file, if the enumeration name ends in EnumX, where X is the size of the enumeration, the code generator uses X as the enumeration size. For example, the RPR-FOM contains an enumeration called ActionEnum32. The size for this enumeration would be 32 bits. If the enumeration is not specified in this format, it is interpreted as 32 bits in size.

7.5.2 Data Types

The VR-Link Code Generator generates files to implement complex data types and their network types. These files are named FomNameTypes.h or .cxx, and FomNameNetTypes.h or .cxx, respectively. If the definition file is an OMT file, these types are generated from the complex data types. If the definition file is an XML file, these types are generated from the combination of simpleDataTypes, arrayDataTypes, fixedRecordDataTypes, and variantRecordDataTypes.

New data types that are used in the object or interaction implementation files are generated. Any components of these types with dynamic (+) cardinality, are generated using STL vectors.

7.5.3 Objects and Interactions

For each object, a DtStateRepository, DtObjectPublisher, DtReflectedObject, DtReflected-ObjectList, DtHlaStateEncoder, and DtHlaStateDecoder is created. For each interaction, a DtInteraction, DtInteractionEncoder, and DtInteractionDecoder is created. Each interaction, publisher, and reflected list knows which FOM object or interaction it corresponds to, so no FOM mapping needs to be done. After code is generated, all you need to do to send or receive an object is instantiate the correct publisher or reflected list. Similarly, to send or receive an interaction, send the appropriate interaction or add a callback to the appropriate interaction. All encoding and decoding is built into the object and interaction classes.

7.5.4 Project Files and Makefiles

Windows project files and UNIX Makefiles are generated with the code. This allows you to build a dynamic library that you can link into application code to incorporate the FOM extensions generated. To build a library, set the environment variables VRLINK_DIR and RTI_DIR to the VR-Link and RTI directories, respectively.

7.5.5 Attributes and Types that Cannot be Decoded and Generated

There are a few instances in which the code generator will not be able to properly generate encoding or decoding of attributes or complex data types, as follows:

• If a complex data type contains more than one component of dynamic cardinality, the code generator cannot generate code to decode this. This is because it cannot determine the size of the two variable length pieces of data.
• If an attribute or complex data type contains a component of variable size data, which is also of variable size, the code generator cannot generate code.
• If the complex data type contains a variant record, the code generator will try to write the code that encodes or decodes it. You should consider the resulting code to be a guideline. The code is surrounded by #if 0, so that it will not be compiled accidentally, and a compiler error will be injected.

In all cases, when you compile, #error is injected to bring attention to the potential problem.

[<< Using the Code Generator] Home] [Top of Page]