Template for stringifying DDS message contents

3 posts / 0 new
Last post
Last seen: 6 years 7 months ago
Joined: 03/09/2016
Posts: 6
Template for stringifying DDS message contents

Does anyone know of a generic way (in cplusplus) to stringify a DDS message? I'm interested in writing a utility to supplement my logging that I can pass a DDS message and its type and get a string or stringstream back.

Fernando Garcia's picture
Last seen: 2 months 1 week ago
Joined: 05/18/2011
Posts: 199

Hi Austin,

Are you generating your types with rtiddsgen or using DynamicData? What version of RTI Connext DDS are you using?

If you are using RTI Connext DDS 5.2.3 or greater and DynamicData there is a hidden set of unsupported undocumented functions that enable you to save an XML or JSON representation of your DynamicData samples in a string buffer. To use these functions you will need to include "ndds/dds_c/dds_c_dynamicdataformatter.h". Note that it is not guaranteed that this functions will be there in future versions and their prototype may change.  Also, if you are using the Modern C++ API you can do something simpler like the following to get a string representation of the sample:

DynamicData data(dynamic_type<SimpleType>::get()); 
data.value("key", 10); 
data.value("value", 20); 
std::ostringstream sout; 
sout << data; 
std::string str = sout.str();

Let me know if this works for you.


jwillemsen's picture
Last seen: 2 years 1 week ago
Joined: 09/24/2013
Posts: 55

The IDL to C++11 wrapper Remedy IT has developed as part of their AXCIOMA product does have support for this out of the box. We generate for each IDL type an ostream insertion which enables you to stream any type as string representation. We also support custom formatters so that you can specialize the formatting in case you don't like the default one. This is all part of our basic IDL to C++11 support which is part of our TAOX11 product.

When you talk about the IDL to C++ language mapping provided by RTI maybe an option is to generate some additional helpers based on your input IDL? Depends on the complexity of the IDL how much work this would be. Using for example using RIDLC as generic IDL front end could speed up the amount of work needed. When you are using the CCK you could consider to enable the TAO_IDL ostream insertion operators but it has been some time ago that we tried to use that and as far as I remember we haven't used it in this combination.