In the past I have always used IDL to describe data types. Now I have a code generator which amongst other things is designed to generate the DDS related code.
One approach is to generate the Dynamic Data API code. The other is to generate IDL and then translate that. I also want to deserialize the incoming data directly into C++ data types such as Eigen::Vector3d etc. Here are my questions
1) Do I lose anything by not using the IDL approach. i.e., is the generated code faster or is the generated when rtiddsgen is used.
2) When data is available, how can I deserialize directly in to my custom data structures.
The key is that I do have a decent code generator using antlr and should be able to generate code. Mimicking rtiddsgen generated output seems like overkill though.
suresh.
Hi,
I've (in the past) auto-generated DynamicData <-> IDL Defined type conversions. So I can unequivocally state that this works in Java (class ExtendedFooType extends FooType {...}).
No idea how to do it in something like C++, sorry.
DynamicData is using reflection and as such means that it will be slower. At the same time most of the RTI tools (Routing Service, for example) hand you a DynamicData object. I use the conversion libraries because it is simpler in some cases to use the FooType instead of its DynamicData variant, so what I lose at runtime (to do the conversion and back) I make up at design time...I write proofs of concept rather than applications, so I'm not worried about runtime latency, I'm interested in getting something running really quickly to show how something can be done using DDS.
rip
Hi Suresh,
I will also take a stab at answering your two questions:
(1) Serialization/Deserialization using the DynamicData API's is definitely going to be slower than the code rtiddsgen generates. All actions in the DynamicData API involve function calls (e.g. to set or get an integer you need to do a function code), some if these functions involve searches to locate a menber by index or by name, etc.
In contrast, the code rtiaddsgen generates is compiled and most of the accesses are resolved by the compiler as memmory offsets.
(2) You can deserialize directly into your own data-structures, but this would involve implementing your own de-serialization routines. You are right that to genetate this code would be significant work that duplicates a lot of with rtiddsgen is doing.
Another option would be to post-process the code that rtiddsgen creates and replace the types that rtiddsgen creates with your own types Eigen::Vector3d. Depending on how differnt these types are from the ones rtiddsgen generates from the IDL description this could be a simple or a more complex transformation.
Yet another option would be to change the XSLT templates that rtiddsgen uses to generate the code. They are located in the directory ndds.5.0.0/resource/rtiddsgen/xml these schemas control the code-generation and they could be changed to use your data-types and accessors. Depending on the change this may be difficult. Also it has the disadvantage that your changes would potentially need to be revisited/updated each time RTI releases a new version of rtiddsgen. Moreover rtiddsgen is moving away from using XSLTs as a way to do the code generation so your work would need to be refactored when the new non-XSLT version of rtiddsgen is released.
How different are the types you want to use from the one rtiddsgen creates? Is this limited to vectors?
One more note is that as we add support for the new DDS ISO-C++ API the vector types would be std::vector so this could perhaps make your changes simpler. The new IDL also supports annotations so this opens the possibility to use annotations to describe the kind of type rtiddsgen should generate (e.g. map a certain sequence to Eigen::Vector3d).
You said your code generator creates DDS-related code. What kind of code are you generating already?
Gerardo