3.2.6. RTI Code Generator¶
The following issues affect backward compatibility in Code Generator starting in Release 6.0.0.
3.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.2.1.3.2.
3.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.2.6.3. Removed -use42eAlignment¶
Starting in 6.0.0, rtiddsgen
no longer supports the -use42eAlignment
option.
See Section 3.1.2.4 for more information.
3.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.1.4.1 for more information.
3.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.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 DDS 6.0.0 will treat the sequences/strings defined in the
XML as unbounded because of the change described in
Section 3.1.4.4.
3.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.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.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).
For additional information on this feature, see “Optimizing the Code Generation Process” in the RTI Code Generator User’s Manual.