Hello,
I'm trying to use the DDS IDL binding to C++ 2011 but the compilation of the C++ classes generated by the rtiddsgen IDL compiler produces a lot of compilation warnings.
I was wondering if there's any recommendation about g++ compiler options to use when compiling the C++ classes generated by the RTI IDL compiler.
Building for standard C++ binding generates classes that produces few warnings at compile time (even if I would prefer no warning to be raised at all).
My build and target environment is Ubuntu 12.04 and g++ 4.6.3 compiler.
I compile the idl with the command:
rtiddsgen -language C++11 -replace Audit.idl
I've attached the simple idl file I'm trying to build (Audit.idl) and the log of the compilation process.
Best regards
Massimo
Attachment | Size |
---|---|
IDL definition file | 1.17 KB |
Output of compilation process | 74.99 KB |
Hi Massimo,
You may have noticed that almost all the warnings are "unused parameter." They are harmless, because they are mostly in implementations of an interface that doesn't require using one of the parameters to the function. This is especially verbose in the Modern C++ API because much of the code is templatized and resides in header files.
We are aware of this problem and are evaluating a solution for future releases.
In the meantime perhaps you can try passing the
-Wno-unused-parameter
flag tog++
. As Alejandro says this is a pretty harmless warning.Gerardo
Note that the warning usually appears enabling a warning level higher than -Wall, such as -W.
Sorry for bringing this topic up but such warnings also appear in the dds header files (not generated) and it's really a pain when you want/have to compile with '-W-unused-parameter' (e.g. because of code policy). A hacky workaround is to use -isystem instead -I for the dds include paths but that's also sometimes not possible. It would be better to get warning-free dds header files :)
Hello Christian (and also Massimo),
I appreciate your feedback. Thank you for explaining how this in combination with corporate policy can become a significant annoyance. Thank you also for pointing out this also happens in distributed header files, not just the generated ones.
I have increased the priority of the internal issue (CPPPSM-373) we had create to address this. Hopefully we can get this removed in the next maintenance or full release.
Gerardo