<<extension>> FlatData Language Binding for IDL topic-types
More...
|
| FlatData Builders |
| A Builder allows creating and initializing variable-size data.
|
|
| FlatData Samples |
| A Sample represents an instance of the IDL topic-type and contains the data in serialized format.
|
|
| FlatData Offsets |
| Offsets provide access to the members of a FlatData Sample.
|
|
<<extension>> FlatData Language Binding for IDL topic-types
- Note
- For a complete description of the FlatData language binding and its benefits, and a tutorial, see the "Sending Large Data" chapter in the RTI Connext User's Manual.
-
For buildable code examples, see https://community.rti.com/kb/flatdata-and-zerocopy-examples.
-
The FlatData language binding is available in the Traditional C++ API and in the Modern C++ API.
RTI FlatData™ is a language binding for IDL types in which the in-memory
representation of a sample matches the wire representation. Therefore, the cost of serialization/deserialization is zero.
To select FlatData as the language binding of a type, annotate it with @language_binding(FLAT_DATA)
in IDL or apply the attribute languageBinding="flat_data"
in XML.
There are some restrictions regarding the kinds of types to which the FlatData language binding can be applied.
- For final types, the FlatData language binding can be applied only to fixed-size types. A fixed-size type is a type whose wire representation always has the same size. This includes primitive types, arrays of fixed-size types, and structs containing only members of fixed-size types. Unions are not fixed-size types.
- For mutable types, any member is permitted.
- Extensible types cannot be marked as FlatData.
Final types are more efficient, but more restrictive. In general, a good compromise is to define mutable top-level types, but making sure their largest data members are final.
When a type is marked with the FlatData language binding, its mapping into C++ is different than that of a regular type (plain language binding). Rather than a single C++ class with direct access to its members, for a FlatData type rtiddsgen generates the following:
- A Sample, the data in serialized format
- An Offset, which allows reading the data members of that type inside a Sample, and modifying them without changing the size
- A Builder, if the type is mutable, which allows creating a variable-size Sample
For example, for the IDL types MyFlatFinal and MyFlatMutable rtiddsgen generates the following C++ types:
Publishing FlatData
The typical way to publish FlatData samples includes the following steps:
(For final topic-types such as MyFlatFinal)
- Obtain a FlatData sample with dds::pub::DataWriter::get_loan.
The generic definition of FlatData topic-types.
Definition: FlatSample.hpp:148
- Initialize the sample, starting from the root() offset.
Represents the Offset to an arbitrary user-defined FlatData final IDL struct.
Definition: Offset.hpp:125
FlatFinalBar::ConstOffset my_complex() const
Retrieves a const Offset to a complex member.
int32_t my_primitive() const
Retrieves the value for a primitive member.
Offset root()
Provides the Offset to the top-level type.
Definition: FlatSample.hpp:181
(For mutable topic-types such as MyFlatMutable)
- Obtain a Builder to create a variable-size sample with rti::flat::build_data().
Represents the Builder for an arbitrary user-defined mutable type.
Definition: Builder.hpp:206
rti::flat::flat_type_traits< TopicType >::builder build_data(dds::pub::DataWriter< TopicType > &writer)
Begins building a new sample.
Definition: FlatDataWriter.hpp:114
- Use this builder (and possibly nested member builders) to initialize the members.
my_mutable_builder.finish();
FlatMutableBarBuilder build_my_mutable()
Begins building a mutable complex member.
MyFlatFinalOffset add_my_final()
Adds a final complex member.
bool add_my_primitive(int32_t value)
Adds a primitive member.
- Obtain the completed sample with MyFlatMutableBuilder::finish_sample(). After that, the builder is no longer usable, and the sample size cannot change.
MyFlatMutable * finish_sample()
Finishes building a sample.
- Optionally, it is possible to change the values of the sample accessing its root(), as long as the size doesn't change. For example, if the sample was built with a sequence member with two elements, it is possible to modify any of those elements, but it's not possible to add a third element.
(For both final and mutable topic-types)
After write, the DataWriter owns the FlatData sample. This allows avoiding additional copies, the main goal of the FlatData language binding. This means that the sample cannot be reused. The DataWriter will return it to the sample pool when appropriate, as described in dds::pub::DataWriter::get_loan.
Subscribing to FlatData
To subscribe to a topic using a FlatData topic-type:
Note that the language binding is a local concept. It is possible to publish with a FlatData topic-type and subscribe to it with a plain topic-type with the same (or assignable) definition. It is also possible to use a plain topic-type on the publisher side and subscribe to it using FlatData. The DataWriter or DataReader of the plain topic-type has to use dds::core::policy::DataRepresentation::xcdr2() in dds::core::policy::DataRepresentation.