Introduction to TypeCode

You are here:

3.1.3 Introduction to TypeCode

Type schemas—the names and definitions of a type and its fields—are represented by TypeCode objects (known as DynamicType in the Modern C++ API). A type code value consists of a type code kind (see the TCKind enumeration below) and a list of members. For compound types like structs and arrays, this list will recursively include one or more type code values.

enum TCKind {
	TK_NULL,
	TK_SHORT,
	TK_LONG,
	TK_USHORT,
	TK_ULONG,
	TK_FLOAT,
	TK_DOUBLE,
	TK_BOOLEAN,
	TK_CHAR,
	TK_OCTET,
	TK_STRUCT,
	TK_UNION
	TK_ENUM,
	TK_STRING,
	TK_SEQUENCE,
	TK_ARRAY,
	TK_ALIAS,
	TK_LONGLONG,
	TK_ULONGLONG,
	TK_LONGDOUBLE,
	TK_WCHAR,
	TK_WSTRING,
	TK_VALUE
}

Type codes unambiguously match type representations and provide a more reliable test than comparing the string type names.

The TypeCode class, modeled after the corresponding CORBA API, provides access to type-code information. For details on the available operations for the TypeCode class, see the API Reference HTML documentation, which is available for all supported programming languages (select Modules, RTI Connext DDS API Reference, Topic Module, Type Code Support or, for the Modern C++ API select Modules, RTI Connext DDS API Reference, Infrastructure Module, DynamicType and DynamicData).

Note: Type-code support must be enabled if you are going to use 5.4 ContentFilteredTopics with the default SQL filter. You may disable type codes and use a custom filter, as described in 5.4.3 Creating ContentFilteredTopics.

3.1.3.1 Sending Type Information on the Network

In addition to being used locally, the type information of a Topic is published automatically during discovery as part of the built-in topics for publications and subscriptions. See 18.2 Built-in DataReaders. This allows applications to publish or subscribe to topics of arbitrary types. This functionality is useful for generic system monitoring tools like the rtiddsspy debug tool (see the API Reference HTML documentation).

Earlier versions of Connext DDS (4.5f and lower) used serialized TypeCodes as the wire representation to communicate types over the network.

The Extensible Types specification (https://www.omg.org/spec/DDS-XTypes/) uses TypeObjects as the wire representation. Types are propagated by serializing the associated TypeObject representation. Connext DDS 5.x and higher supports TypeObjects as the wire representation. To maintain backward compatibility with previous releases, Connext DDS still supports propagation of TypeCodes; however, support for this feature may be discontinued in future releases.

If your data type has an especially complex type code, you may need to increase the value of the type_code_max_serialized_length, type_object_max_serialized_length, and type_object_max_deserialized_length fields in the DomainParticipant's 9.5.4 DOMAIN_PARTICIPANT_RESOURCE_LIMITS QosPolicy (DDS Extension). Or, to prevent the propagation of type information altogether, you can set these values to zero (0). Be aware that some features of monitoring tools, as well as some features of the middleware itself (such as ContentFilteredTopics) will not work correctly if you disable type information propagation.

For additional information on TypeCode versus TypeObject as wire representation, as well as resource limits to configure the propagation, see "TypeRepresentation" in the RTI Connext DDS Core Libraries Getting Started Guide Addendum for Extensible Types.