This section describes the conventions used in the API documentation.
Unsupported Features
[Not supported (optional)] 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
- <<extension>>
- 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.
Experimental
- <<experimental>>
- 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 method 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 method.
Method Parameters