6.2.6. RTI Code Generator

The following issues affect backward compatibility in Code Generator starting in Release 6.0.0.

6.2.6.1. Removed -stl Option

In 6.0.0, the -stl command-line option has been removed because now it is the default behavior when running rtiddsgen. For more information, see Section 6.2.1.2.1.

6.2.6.2. Removed Support for -notypecode

Starting in 6.0.0, rtiddsgen no longer supports the -notypecode option. If you try to use this option, code generation will fail with this error:

ERROR com.rti.ndds.nddsgen.Main Fail:  com.rti.ndds.nddsgen.Main$ArgumentException: -notypecode is no longer supported.

Beginning with 6.0.0, type code information is always generated, but it is surrounded by:

#ifndef NDDS_STANDALONE_TYPE
#endif

When using standalone types, you already have to add the preprocessor definition NDDS_STANDALONE_TYPE. This definition now also leads to the exclusion of type code. For more information about how to use standalone types, see the “Using Generated Types without Connext DDS (Standalone)” section in the RTI Connext DDS Core Libraries User Manual.

6.2.6.3. Removed -use42eAlignment

Starting in 6.0.0, rtiddsgen no longer supports the -use42eAlignment option. See Section 6.1.1.4 for more information.

6.2.6.4. Generated code for Extended CDR Encoding Version 2 (XCDR2)

Starting in 6.0.0, RTI code generation now supports generating code for the Extended Common Data Representation (CDR) encoding version 2 (XCDR2), in addition to version 1 (XCDR). See Section 6.1.3.1 for more information.

6.2.6.5. Incorrect TypeCode name for member fields whose name was a keyword in Java

Prior to 6.0.0, when generating the TypeCode name for members whose name was a keyword in Java, Code Generator added a _ as a prefix to that name. That could cause problems when communicating between a Java application and a C/C++/.Net application using that type because the types will not match out-of-the-box. For example:

struct MyType {
    long class; /* class is a keyword in Java */
    ...
};

When generating Java code for the above type, Code Generator generated a TypeCode name _class for the member class.

In 6.0.0, that prefix has been removed. That removal, however, could cause a backward compatibility problem when communicating between a Java application in 6.0.x and one in a previous release, if the name of the members is a keyword in Java.

6.2.6.6. Modified maximum length of sequences and strings when -unboundedSupport is not used, when converting to XML

Prior to 6.0.0, when Code Generator converted a type from IDL to XML, and that type contained an unbounded sequence, and -unboundedSupport was not used, the length of any sequence was -1. Now in Connext 6, when -unboundedSupport is not used, the length of any unbounded sequence is 100, and the length of any unbounded string is 255. (When -unboundedSupport is used, the length of both is still -1.) These values (100 and 255) can be changed by using the options -sequenceSize and -stringSize.

If you generated XML in previous releases from an IDL containing unbounded sequences/strings, without using -unboundedSupport, you will have to regenerate the XML using the new Code Generator (without -unboundedSupport). This regeneration will put explicit (bound) limits on the sequences/strings. Otherwise, Connext 6.0.0 will treat the sequences/strings defined in the XML as unbounded because of the change described in Section 6.1.3.4.

6.2.6.7. Traditional C++ compiled with -fno-exceptions

Starting in 5.3.0, the generated code for traditional C++ could not be compiled with the flag -fno-exceptions, producing an error similar to this one:

In file included from Hello.cxx:215:0:
rti_connext_dds-5.3.0/include/ndds/dds_c/generic/dds_c_sequence_TSeq.gen: In function ‘DDS_Boolean HelloSeq_set_maximum(HelloSeq*, DDS_Long)’:
rti_connext_dds-5.3.0/include/ndds/dds_c/generic/dds_c_sequence_TSeq.gen:548:32: error: exception handling disabled, use -fexceptions to enable
         } catch (std::bad_alloc&) {

This issue has been resolved in 6.0.0: the code will not report errors, provided that you generate code with the -allocateWithMalloc command-line option. This option disables the generation of default constructors/destructors and allocates the optional members using DDS_Heap_malloc.

6.2.6.8. Support for new, standard IDL, fixed-width integer types

Release 6.0.0 introduces a new set of standard, fixed-width integer types to improve the readability of IDL files. These types are int16, int32, int64, uint16, uint32, and uint64, which are equivalent to the respective short, long, long long, unsigned short, unsigned long, and unsigned long long classic integer types. As a result, if you defined those types in your user IDL with typedefs, such as:

typedef long long int64;

Code Generator will fail to generate code, and you should remove the typedef from the IDL.

For the same reason, int8 and uint8, although not supported, cannot be used as part of the IDL, either.

6.2.6.9. Change in default optimization level for code generation

As described in “What’s New in 3.0.0” in the Code Generator Release Notes (in “New optimization level for code generation”), the default optimization level for code generation for C, C++, and Ada languages has changed from 0 to 2 in release 6.0.0. This can increase the performance of the serialize/deserialize operations significantly in some cases. With optimization level 2, rtiddsgen optimizes the serialization/deserialization of structures and valuetypes by using more aggressive techniques, such as inline expansion of nested types or serialization of several consecutive members with a single copy (memcpy).

The new default optimization also affects the generation of types in the target language by resolving typedef types when possible. If a type that is used is a typedef that can be resolved to a primitive, enum, or aggregated type (struct, union, or value type), the generated code will replace the typedef with the most basic type to which the typedef can be resolved. For example, consider the following IDL:

typedef string<255> MyString;
typedef MyString MyElement;
typedef sequence<MyElement,10> MyElementList;

With optimization 0 (in C++), the generated code contains:

typedef    DDS_Char *   MyString;
typedef    MyString  MyElement;
typedef    MyElementSeq  MyElementList;

With optimization 2 (in C++), the generated code contains:

typedef    DDS_Char *   MyString;
typedef    DDS_Char *   MyElement;
typedef    DDS_StringSeq  MyElementList;

The replacement of typedef types with equivalent non-typedef types does not require application code changes in most cases. However, there is a corner case involving the const qualifier and sequences of strings that will require application code changes.

For example, the following code using the previous IDL will not compile with optimization level 1 or 2, and will have to be changed:

void printSomeElement(const MyElement& element) {
    printf(element);
    printf("\n");
}

void printMyElementList(const MyElementList& list) {
    int size = list.length();
    for (int i = 0; i < size; i++) {
        printSomeElement(list[i]);
    }
}

You would receive the following error:

element.cxx:248:9: error: no matching function for call to 'printSomeElement'
        printSomeElement(list[i]);
        ^~~~~~~~~~~~~~~~
element.cxx:240:6: note: candidate function not viable: 1st argument ('const char *') would lose const qualifier
void printSomeElement(const MyElement& element) {

For additional information on the default optimization level, see “Optimizing the Code Generation Process” in the RTI Code Generator User’s Manual.