Conventions

This section describes the conventions used in the API documentation.

Unsupported Features

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

API Documentation Terms

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

Stereotypes

Commonly used stereotypes in the API documentation include the following.

Extensions

- <<ext>> - An RTI Connext 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 such as pluggable transports.

- <<exp>> - RTI Connext experimental features are used to evaluate new features and get user feedback. - These features are not guaranteed to be fully supported and might be implemented only of some of the programming languages supported bt RTI Connext - The functional APIs corresponding to experimental features can be distinguished from other APIs by the suffix '_exp'. - Experimental features may or may not appear in future product releases. - The name of the experimental features APIs will change if they become officially supported. At the very least the suffix '_exp' will be removed. - Experimental features should not be used in production.

Types

- <<interface>> - Pure interface type with no state. - Languages such as Java natively support the concept of an interface type, which is a collection of procedure signatures devoid of any dynamic state. - In C++, this is achieved via a class with all pure virtual methods and devoid of any instance variables (ie no dynamic state). - Interfaces are generally organized into a type hierarchy. Static typecasting along the interface type hierarchy is "safe" for valid objects.

- <<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 procedure.

Method Parameters

- <<in>> - An input parameter.

- <<out>> - An output parameter.

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