.. include:: /../getting_started/vars.rst .. _section-Product-Codegen: RTI Code Generator ****************** The following issues affect backward compatibility in *Code Generator* starting in Release 6.0.0. 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 :numref:`section-Product-STL`. 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: .. code-block:: text 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: .. code-block:: text #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 :link_connext_gentype_usersman:`the "Using Generated Types without Connext DDS (Standalone)" section in the RTI Connext DDS Core Libraries User Manual <>`. Removed -use42eAlignment ======================== Starting in 6.0.0, ``rtiddsgen`` no longer supports the ``-use42eAlignment`` option. See :numref:`section-General-42e_alignment` for more information. 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 :numref:`section-General-Extended-CDR` for more information. 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: .. code-block:: text 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. 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 :numref:`section-General-Unbounded`. 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: .. code-block:: text 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``. 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: .. code-block:: text 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. .. _section-Codegen-Opt: Change in default optimization level for code generation ======================================================== As described in :link_connext_codegen_new_release_notes:`"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: .. code-block:: omg-idl typedef string<255> MyString; typedef MyString MyElement; typedef sequence MyElementList; With optimization 0 (in C++), the generated code contains: .. code-block:: C++ typedef DDS_Char * MyString; typedef MyString MyElement; typedef MyElementSeq MyElementList; With optimization 2 (in C++), the generated code contains: .. code-block:: C++ 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: .. code-block:: C++ 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: .. code-block:: text 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 :link_codegen_opt_usersman:`"Optimizing the Code Generation Process" in the RTI Code Generator User's Manual <>`.