Type Code Support

<<ext>> A DDS_TypeCode is a mechanism for representing a type at runtime. RTI Connext can use type codes to send type definitions on the network. You will need to understand this API in order to use the DDSDynamicDataModule capability or to inspect the type information you receive from remote readers and writers.

Modules

Summary: <<ext>> A DDS_TypeCode is a mechanism for representing a type at runtime. RTI Connext can use type codes to send type definitions on the network. You will need to understand this API in order to use the DDSDynamicDataModule capability or to inspect the type information you receive from remote readers and writers.

Type codes are values that are used to describe arbitrarily complex types at runtime. Type code values are manipulated via the DDS_TypeCode class, which has an analogue in CORBA.

A DDS_TypeCode value consists of a type code kind (represented by the DDS.TCKind enumeration) and a list of members (that is, fields). These members are recursive: each one has its own DDS_TypeCode, and in the case of complex types (structures, arrays, and so on), these contained type codes contain their own members.

There are a number of uses for type codes. The type code mechanism can be used to unambiguously match type representations. The DDS_TypeCode.equal procedure is a more reliable test than comparing the string type names, requiring equivalent definitions of the types.

Accessing a Local DDS_TypeCode

When generating types with DDSNddsgenModule, type codes are always enabled. For these types, a DDS_TypeCode may be accessed via the FooTypeCode.VALUE member. This API also includes support for dynamic creation of DDS_TypeCode values, typically for use with the DDSDynamicDataModule API. You can create a DDS_TypeCode using the DDS_TypeCodeFactory class. You will construct the DDS_TypeCode recursively, from the outside in: start with the type codes for primitive types, then compose them into complex types like arrays, structures, and so on. You will find the following methods helpful:

  • DDS_TypeCodeFactory.get_primitive_tc, which provides the DDS_TypeCode instances corresponding to the primitive types (e.g. DDS.TK_LONG, DDS.TK_SHORT, and so on).
  • DDS_TypeCodeFactory.create_string_tc and DDS_TypeCodeFactory.create_wstring_tc create a DDS_TypeCode representing a text string with a certain bound (i.e. maximum length).
  • DDS_TypeCodeFactory.create_array_tc and DDS_TypeCodeFactory.create_sequence_tc create a DDS_TypeCode for a collection based on the DDS_TypeCode for its elements.
  • DDS_TypeCodeFactory.create_struct_tc and DDS_TypeCodeFactory.create_value_tc create a DDS_TypeCode for a structured type.

    Accessing a Remote DDS_TypeCode

    In addition to being used locally, RTI Connext can transmit DDS_TypeCode on the network between participants. This information can be used to access information about types used remotely at runtime, for example to be able to publish or subscribe to topics of arbitrarily types (see DDSDynamicDataModule). This functionality is useful for a generic system monitoring tool like rtiddsspy.

    Remote DDS_TypeCode information is shared during discovery over the publication and subscription built-in topics and can be accessed using the built-in readers for these topics; see DDSBuiltInTopicModule. Discovered DDS_TypeCode values are not cached by RTI Connext upon receipt and are therefore not available from the built-in topic data returned by DDS.DataWriter.get_matched_subscription_data or DDS.DataReader.get_matched_publication_data.

    The space available locally to deserialize a discovered remote DDS_TypeCode is specified by the DDS.DomainParticipant's DDS.DomainParticipantResourceLimitsQosPolicy.type_code_max_serialized_length QoS parameter. To support especially complex type codes, it may be necessary for you to increase the value of this parameter.


    See also: DDS_TypeCode
    See also: DDSDynamicDataModule
    See also: DDSNddsgenModule
    See also: DDS.SubscriptionBuiltinTopicData
    See also: DDS.PublicationBuiltinTopicData