Translation for IDL types problem

6 posts / 0 new
Last post
Offline
Last seen: 5 years 3 weeks ago
Joined: 08/13/2014
Posts: 55
Translation for IDL types problem

Hi

I have two questions:

1- Is it possible to stop translation for enum types in rtiddsgen? I mean something like "@resolve-name off" but for the whole enum. 

2- Does "rti recording service" have any problems with the types in IDL file indicated with "@resolve-name off" directive?

Thanks in advance for your help.

Bonjefir

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 10 hours ago
Joined: 06/02/2010
Posts: 602

Hi,

Regarding question #1 would ne Ied to understand more about what you are trying to do. Can you attache an example IDL and explain a bit more why you do not want the enum to be resolved in the IDL?  Do you mean that you do not have the enum declaration the same IDL file? Also what is programming language are you using? I can think of some solutions but they are programming-language specific..

Regarding question #2. The @resolve-name does not affect the type being generated. What it does is a "forward declaration" to tell rtiddsgen to allow the type to be referenced from other types and not give an error even if the type definition is not in the IDL files known to the rtiddsgen execution. However those types still need to be generated (e.g. by a separate execution of rtiddsgen on a differnt IDL file) and all the resulting files linked together. So at run-time from the recorder perspective there are ony two situations: Either the type of the data being recorder is known (e.g. via discovery-propagated typecodes) or not.  Either situation is indepedent of the presence of the @resolve-name in the IDL. That only affects the checking performed by rtiddsgen not the end code being compiled.

Gerardo

Offline
Last seen: 5 years 3 weeks ago
Joined: 08/13/2014
Posts: 55

Hi Gerardo

First thanks for your nice and comprehensive answer. About question #1, please take a look at this: https://community.rti.com/forum-topic/how-use-generated-enums-rtiddsgen-modern-c-code

About the second question, I'm almost get your answer but there is only one question left. Based on your answer, RTI recording service won't record data if its type is unknown. Is it true?

Bonjefir

Offline
Last seen: 7 years 2 weeks ago
Joined: 09/17/2015
Posts: 53

You can edit the c++03 templates of rtiddsgen2. So you can apply perhaps generate code alongside http://stackoverflow.com/questions/17823800/typedef-and-enum-or-enum-class to emulate classical c enums. 

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 10 hours ago
Joined: 06/02/2010
Posts: 602

Hello Bonjefir,

Thank you for the reference. I understand this is pretty annoying when migrating the Enums from the tradicitonal to the new C++. I think editing the C++03 templates, as robuser suggests,  may be the only workaround if you do not want to migrate all the code. If you are migrating the code then perhaps using a smart editor that supports refactoring can help make it less painful.

Was this the main source of pain migrating from the Traditional C++ to the Modern C++ API? If so I think we may want to consider adding an option to support the old style enums to alliviate other users that want to migrate...

Regarding RTI Recording Service recoding data whose type is unknown.  This is indeed possible. This is described in Section 4.7 (Domain Properties) of the RTI Recording Service Users Manual.  To do this you need to specify

 <deserialize_mode>RTIDDS_DESERIALIZEMODE_AUTOMATIC</deserialize_mode>

This is done inside the <domain> section in the Recording Service XML configuration file.

With this configuration the data will be recorded in deserialized mode if the type is known and in serialized mode if the type is not known.

Gerardo

Offline
Last seen: 5 years 3 weeks ago
Joined: 08/13/2014
Posts: 55

Dear Gerardo,

Thanks for your nice and comprehensive answer and suggestion. I had to migrate the enum from traditional C++ to the Modern C++ API. But I welcome your suggestion to add an option to support the old style enums.

Best Regards,

Bonjefir