3.2.2.2. RTI Code Generator

3.2.2.2.1. -language C++03 will soon be removed

The Code Generator option -language C++03 has been deprecated and may be removed in a future version. After it is removed, the Modern C++ API will require a C++11 compiler or newer. (The Traditional C++ API will continue to support C++98 and newer compilers.)

In this release, for the Modern C++ API, it is recommended that you stop using the -language C++03 option and use -language C++11 instead. (For the Traditional C++ API, you can continue to use -language C++.)

Please contact support@rti.com if you need to continue using the deprecated option.

3.2.2.2.2. -legacyPlugin option removed

The Code Generator option -legacyPlugin has been removed and is not supported in this release.

3.2.2.2.3. Modern C++ API now maps enums to enum class

This release changes the mapping of IDL enum to C++11.

Given the following IDL definition:

enum Color { red, green, blue };

struct Shape  {
    Color color;
    // ...
};

The previous mapping of Color to C++ was as follows:

Listing 3.15 Before updating to 6.1.0

struct Color_def {
    enum type {
        red,
        green,
        blue
    };
};
typedef ::dds::core::safe_enum< Color_def > Color;

Starting in this release, when -language C++11 is used, the mapping is to enum class:

Listing 3.16 After updating to 6.1.0

enum class Color {
    red,
    green,
    blue
};

In some cases, application code may need to be updated. The previous mapping required calling the underlying() member function in some situations to obtain the enumerator, for example:

Listing 3.17 Before updating to 6.1.0

Shape shape;
shape.color(Color::red);

switch (shape.color().underlying()) {
case Color::red:
    std::cout << "red\n";
    // ...
}

That code needs to be updated to remove any use of the underlying() function:

Listing 3.18 After updating to 6.1.0

Shape shape;
shape.color(Color::red);

switch (shape.color()) {
case Color::red:
    std::cout << "red\n";
    // ...
}

3.2.2.2.4. IDL type incompatibility: @key should no longer be set in derived structures

Previously, @key fields could be set in a derived structure.

However, the OMG ‘Extensible and Dynamic Topic Types for DDS’ specification, version 1.3 states the following:

“A Structure Type may inherit from another Structure Type as long as the following conditions are met:”

One of the conditions is the following:

“The derived type does not define any key fields. This ensures the key fields of the derived type are the same as those of the base root type.”

In this release, to support the specification while preserving backwards compatibility, Code Generator will report an informational (INFO) message for keyed derived structures when running rtiddsgen, but still generate code. If you want Code Generator to enforce the specification, use the -strict option when running rtiddsgen. This option will report an error when there are keyed derived structures, and not generate code. See the Code Generator User’s Manual for more information.