5.12. Dynamic Data

5.12.1. [Major] Incorrect DynamicData behavior involving empty structures

Creating a new DynamicData instance from an empty structure incorrectly failed. For example, consider the following Modern C++ code snippet:

using namespace dds::core::xtypes;

    StructType foo(
        "Foo", {}
    );

    StructType myFoo("Foo");
    DynamicData dynFoo(myFoo);

“Foo” is an empty structure. Its lack of members caused the constructor to fail with the following error:

DDS_DynamicData2_allocateMembers: Could not reserve buffer of 0 bytes for values.

This problem affected all language APIs and has been fixed. DynamicData creation from an empty structure now succeeds.

The JSON-formatted string for a DynamicData sample was malformed if the sample had a base structure that was empty. For example, consider the following IDL:

struct EmptyStruct {};

struct StructWithEmptyBaseStruct : EmptyStruct {
    short x;
};

and the following Modern C++ code snippet:

DynamicData struct_with_empty_base_struct_dd(dynamic_type<StructWithEmptyBaseStruct>::get());
    std::string str = rti::topic::to_string(
            struct_with_empty_base_struct_dd,
            PrintFormatProperty::Json());

The resulting str would look like {,"x":0}. The leading comma is considered a JSON syntax error. This problem has been fixed by removing this comma, so the str will now look like {"x":0}.

[RTI Issue ID CORE-14606]

5.12.2. [Major] DynamicData to and from JSON conversion did not include union discriminators

The discriminator value was not included in the JSON string produced by DynamicData::to_json. This could have caused a loss of information regarding what the discriminator was when there were multiple options. This behavior has been fixed, and the discriminator is now printed when needed.

[RTI Issue ID CORE-14259]

5.12.3. [Minor] DynamicData::get_member_info API returned incorrect member_id in some cases

When the DynamicData::get_member_info API was called for a member of a union that could be selected by multiple union discriminator values, the returned DynamicDataMemberInfo::member_id field was always set to the discriminator value of the first case label for that member. The correct behavior when the member_id was provided to the API in order to identify the member about which to get the information is to return the provided member_id in the DynamicDataMemberInfo::member_id field. For example, for the following union:

union Foo switch(short) {
case 1:
    long member1;
case2:
case3:
    long member2;
};

the following:

DDS_DynamicData_get_member_info(dynData, &info, 3, null);

returned info.member_id = 2, because 2 is the first label. Now, it correctly returns 3, the provided member_id.

[RTI Issue ID CORE-14583]