Description of RTI Connext Micro C++ support. More...

Modules
	Supported API
	A list of APIs natively supported in C++.

Detailed Description

Description of RTI Connext Micro C++ support.

Overview

RTI Connext Micro support for the C++ language includes native APIs that are built around the C-based core implementation.

The C++ API has been implemented on top of the existing C API in order to minimize duplication of implementation and maximize reuse of existing features.

The two APIs should not be mixed and an application should only include the header file for either one of the two.

The following sections will present in further detail how existing functionalities have been exposed to C++ applications.

DCPS Entities

The API makes use of C++ object-oriented features to define several classes that represent the entities of the DDS DCPS. These classes will be used by application in place of the data types defined by the C API. The following table provides a list of the C++ classes and the corresponding C type they replace:

C++ Class	C Type
DDSDomainParticipantFactory	DDS_DomainParticipantFactory
DDSDomainParticipant	DDS_DomainParticipant
DDSPublisher	DDS_Publisher
DDSSubscriber	DDS_Subscriber
DDSTopic	DDS_Topic
DDSDataWriter	DDS_DataWriter
DDSDataReader	DDS_DataReader

Supported operations for each entity are exposed as class instance methods. It is important to note that instances of these classes cannot be used as arguments to the corresponding functions that implement the operations in C.

The page Supported API presents a complete list of the operations supported by the C++ API.

Support Data Types

In addition to DCPS entities, RTI Connext Micro C++ API also includes several support data types which are required to fully leverage the DDS API. These data types include:

QoS structures for DCPS entities (i.e. DDS_DomainParticipantFactoryQos, DDS_DomainParticipantQos, DDS_PublisherQos, DDS_SubscriberQos, DDS_TopicQos, DDS_DataWriterQos, DDS_DataReaderQos).
Sequence types (e.g. FooSeq)

Differently from DCPS entities, these data types are not defined independently by the C++ API. Instead, their existing declarations, contained in the header files of the underlying C API, have been conditionally modified to include C++ "features" when accessed from a C++ application.

While this makes it possible to use the existing C functions, it is highly recommended that application rely only on the corresponding C++ methods that are defined for each data type.

These "converted" data types define a default constructor which automatically initializes an instance of the type by invoking its C initialize function. A destructor is also provided, which relies on the C finalize function.

C Data Types

Some functionalities that might be required by application have not been exposed by the C++ layer yet and they will require applications to use the existing C API in order to access them.

The following types and their operations are available only through the C API:

RT_Registry_T
struct DDS_Duration_t
struct DDS_Time_t
DDS_InstanceHandle_t
struct DDS_GUID_t
struct DDS_SequenceNumber_t
struct DDS_QosPolicyCount
All QosPolicy structures
struct DDS_ProductVersion

C++ Safety Certification Support

With safety certifiability as a future goal, the RTI Connext Micro C++ API has been designed with the following behavior:

No polymorphic behavior is included in the API.
Exceptions are not thrown by the API methods.

Polymorphism

Since polymorphism is avoided by the API, some operations required renaming in order to be properly implemented.

In particular, the DDSDataWriter and DDSDataReader classes both expose methods that accept generic arguments of type void*. The DDS DCPS typically allows these methods to be overloaded by typed subclasses that are generated to support user-defined data types. While this pattern is naturally supported by the C++ language, the exclusion of polymorphism forced the renaming of the generic operations by appending the suffix "_untyped".

These untyped operations can be used with arguments of user-defined data types and they in fact provide the implementation for their "typed" counterpart presented by subclasses.