Documentation Guide

This section describes the conventions used in the API documentation.

Unsupported Features

[Not supported.] This note means that the feature from the DDS specification is not supported in the current release.

API Naming Conventions

Structure & Class Names

RTI Connext DDS Micro makes a distinction between value types and interface types. Value types are types such as primitives, enumerations, strings, and structures whose identity and equality are determined solely by explicit state. Interface types are those abstract opaque data types that conceptually have an identity apart from their explicit state. Examples include all of the subtypes. Instances of value types are frequently transitory and are declared on the stack. Instances of interface types typically have longer lifecycles, are accessible by pointer only, and may be managed by a factory object.

Value type structures are made more explicit through the use of C's structure tag syntax. For example, a object must be declared as being of type "struct DDS_Duration_t," not simply "DDS_Duration_t." Interface types, by contrast, are always of typedef'ed types; their underlying representations are opaque.

API Documentation Terms

In the API documentation, the term module refers to a logical grouping of documentation and elements in the API.

At this time, typedefs that occur in the API, such as do not show up in the compound list or indices. This is a known limitation in the generated HTML.

Stereotypes

Commonly used stereotypes in the API documentation include the following.

Extensions

• <<eXtension>>
  • An RTI Connext DDS Micro product extension to the DDS standard specification.
  • The extension APIs complement the standard APIs specified by the OMG DDS specification. They are provided to improve product usability and enable access to product-specific features.

Types

• <<interface>>
  • Pure interface type with no state.

• <<generic>>
  • A generic type is a skeleton class written in terms of generic parameters. Type-specific instantiations of such types are conventionally referred to in this documentation in terms of the hypothetical type "Foo"; for example: FooSeq, FooDataType, FooDataWriter, and FooDataReader.

• <<singleton>>
  • Singleton class. There is a single instance of the class.
  • Generally acccessed via a get_instance() static function.

Method Parameters

• <<in>>
  • An input parameter.

• <<out>>
  • An output parameter.

• <<inout>>
  • An input and output parameter.

Cert API

• <<cert>>
  • Supported in safety certified version of RTI Connext DDS Micro. Note, specific fields of <<cert>> data structures may not be supported and will be described in documentation as unsupported.

Underliying FACE Profile

• <<Connext Micro>>
  • Supported only when the underliying DDS version is RTI Connext DDS Pro.

• <<Connext Pro>>
  • Supported only when the underliying DDS version is RTI Connext DDS Micro.

Underliying FACE Profile

• <<SafetyBase or Stricter>>
  • Supported for the SafetyBase or stricter FACE profiles.

If none of <<Connext Micro>> nor <<Connext Pro>> is specified, the symbol is available on both underliying versions of RTI Connext DDS.