.. include:: ../../../router.1.0/srcDoc/vars.rst

.. _section-Product-Codegen:

RTI Code Generator
******************
The following issues affect backward compatibility in the *Code Generator*.


Removed -stl Option
===================

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
===============================

``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.


In this release, 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
========================

``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)
==========================================================

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
==========================================================================

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**.

That prefix has been removed in this release. That removal,
however, could cause a backward compatibility problem when communicating
between a Java application in 6.0.0 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
===========================================================================================================

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 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: 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
========================================================
This release 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. 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 
:link_codegen_opt_usersman:`"Optimizing the Code Generation Process" in the RTI Code Generator User's Manual <>`.