3.4.2.6. RTI Code Generator
The following issues affect backward compatibility in Code Generator starting in Release 6.0.0.
3.4.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 3.4.2.1.2.1.
3.4.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.
3.4.2.6.3. Removed -use42eAlignment
Starting in 6.0.0, rtiddsgen no longer supports the -use42eAlignment option.
See Section 3.4.1.1.4 for more information.
3.4.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 3.4.1.3.1 for more information.
3.4.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.
3.4.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 3.4.1.3.4.
3.4.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.
3.4.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.
3.4.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.