6.6.8. Fixes Related to APIs
6.6.8.1. [Major] Copy of SampleInfo::coherent_set_info field was not supported
SampleInfo::coherent_set_info was not available when using take/read operations that did not loan the samples. The SampleInfo::coherent_set_info field was always set to NULL when you called the take/read operations that did not loan the samples. To get the coherent_set_info value, you had to use the read/take operations that loan the data.
In addition, the copy constructor and assignment operator in the Traditional C++ and Modern C++ APIs did not copy the SampleInfo::coherent_set_info field. This field was always set to NULL; it was your responsibility to make the copy and handle memory allocation and deletion for this field.
This problem has been fixed. If you work with the C API, starting with this release you will have to use the following functions to manipulate SampleInfo structures:
DDS_SampleInfo_initialize()
DDS_SampleInfo_copy()
DDS_SampleInfo_finalize()
[RTI Issue ID CORE-11213]
6.6.8.2. [Major] Corruption of LoanedDynamicData object when moved in some situations (Modern C++ API only)
Given a DynamicData sample, accessing a nested member within another nested member via loan_value() and then moving the latter may have corrupted the former. For example, given a sample such that “my_sample.a.b” is a member of a constructed type (struct or union):
DynamicData my_sample(my_dynamic_type);
LoanedDynamicData loan1 = my_sample.loan_value(""a"");
LoanedDynamicData loan2 = loan1.get().loan_value(""b"");
// The following corrupts loan2
LoanedDynamicData loan1_moved = std::move(loan1);
This may have affected applications that explicitly move-constructed a double-nested LoanedDynamicData or that otherwise indirectly called the move constructor in this situation (for example, by resizing a std::vector of LoanedDynamicData elements).
The LoanedDynamicData’s move constructor and move-assignment operators have been fixed.
[RTI Issue ID CORE-12272]
6.6.8.3. [Major] Calling DynamicData::set_complex_member with an aliased type failed
Calling DynamicData::set_complex_member() with an aliased type failed. For example, given the following types:
struct Foo {
long x;
long y;
};
typedef Foo TypedefFoo;
struct MyType {
Foo my_inner_struct;
TypedefFoo my_typedef_struct;
};
The following code should have worked to set the my_typedef_struct member:
struct Foo {
long x;
long y;
};
typedef Foo TypedefFoo;
struct MyType {
Foo my_inner_struct;
TypedefFoo my_typedef_struct;
};
DDS_DynamicData *data = DDS_DynamicData_new(
MyType_get_typecode(),
&DDS_DYNAMIC_DATA_PROPERTY_DEFAULT);
DDS_DynamicData *inner_data = DDS_DynamicData_new(
TypedefFoo_get_typecode(),
&DDS_DYNAMIC_DATA_PROPERTY_DEFAULT);
// This call fails. If the above call used Foo_get_typecode instead then it would work
retcode = DDS_DynamicData_set_complex_member(data, ""my_typedef_struct"", 0, inner_data);
if (retcode != DDS_RETCODE_OK) {
fprintf(stderr, ""_set_complex_member %d\n"", retcode);
return -1;
}
But instead, it failed with these errors:
DDS_DynamicData2_copy: Objects have different types. self type = TypedefFoo, other type = TypedefFoo
DDS_DynamicData2_finalize_ex: finalizing object bound to a member, automatically unbinding now.
DDS_DynamicData2_set_complex_member:ERROR: Failed to copy value
DDS_DynamicData2_unbind_complex_member:ERROR: Bad parameter: self has no bound member
DDS_DynamicData2_set_complex_member:!unbind complex member
This issue has been fixed. Now, using either the aliased type (TypedefFoo in our example) or the original type (Foo in our example) works to set a complex member using the DynamicData API.
[RTI Issue ID CORE-12273]
6.6.8.4. [Major] Possible wrong results when adding Time or Duration objects that used very large numbers
Adding Time or Duration objects could have previously produced wrong results when using very large numbers. Necessary checks are now in place to ensure that wrong results do not occur.
[RTI Issue ID CORE-12413]
6.6.8.5. [Major] Java API did not support RtpsReliableReaderProtocol_t.receive_window_size
This QoS setting was ignored by the Java API, and readers were always created with the default value (256). This problem has been resolved.
[RTI Issue ID CORE-12451]
6.6.8.6. [Minor] Input parameters to Property and DataTag helper functions do not have “const”
In the C API, the following functions were incorrectly missing a const before the policy parameter:
DDS_PropertyQosPolicyHelper_lookup_property()
DDS_PropertyQosPolicyHelper_lookup_property_with_prefix()
DDS_PropertyQosPolicyHelper_get_properties()
DDS_DataTagQosPolicyHelper_lookup_tag()
This problem has been fixed. The policies are now “const” because these functions do not change the policy.
[RTI Issue ID CORE-3166]
6.6.8.7. [Minor] Standard 64-bit integer types are now supported (Modern C++ API)
Previous releases of the Modern C++ API had platform-specific definitions for 64-bit integers, defined in rti::core::int64 and rti::core::uint64. This was required to support certain pre-C++11 platforms.
This release redefines those two types as std::int64_t and std::uint64_t.
[RTI Issue ID CORE-10913]
6.6.8.8. [Minor] Assigning DataWriter and DataReaderQos from a TopicQos caused a build error
DataWriterQos and DataReaderQos could not be constructed from a TopicQos assignment. You may have seen a compiler error such as:
error: conversion from 'TEntityQos<rti::topic::qos::TopicQosImpl>' to
non-scalar type 'TEntityQos<rti::pub::qos::DataWriterQosImpl>' requested.
This problem has been resolved. Now this type of assignment works correctly. Any fields that are not in the TopicQos will use the default for the DataWriterQos or DataReaderQos.
[RTI Issue ID CORE-11185]
6.6.8.9. [Minor] In XML-based applications, generated IDL types did not take precedence over XML DynamicTypes (C# API)
In the C# API in previous releases, if a type was declared in XML as a dynamic type and also generated and registered by the application, the XML dynamic type took precedence. This led to the DataReaders or DataWriters using DynamicData instead of the generated C# user class. This behavior was unintuitive and inconsistent with the other language APIs. It has been resolved.
[RTI Issue ID CORE-11389]
6.6.8.10. [Minor] Namespaces ignored when a type was explicitly registered in C# for XML-based applications
When a type was explicitly registered (this is only necessary to support generated IDL types with XML-Based Application Creation) as follows:
DomainParticipantFactory.RegisterType<A.B.Foo>()
The registered type name was to set to “Foo” instead of the expected “A::B::Foo”. In some situations, this may have stopped applications written in other languages to communicate with a C# application, if the regular algorithm of type matching was disabled.
[RTI Issue ID CORE-12074]