I am working on a project that will send 50+ topic types between device(s) and a central controlling app.
In my experience so far it seems that a matching publisher & subscriber will only work with the same topic type. I don't want to write publish and subscribe functions specific to each topic (I won't live long enough...).
Is there a way that DDS can accept generic topics? I tried fooling it with regular C++ polymorphism, by creating a base class, and derived classes each containing the various topic structures. I hoped I could create a topic of the base class type and pass it a derived object. But DDS wasn't fooled alas.
I got the message "Type T must be a DDS topic type". My classes contained topics, but weren't topics themselves. It wanted an is a relationship, not a has a one.
DDS allows type evolution (including inheritance) as a distributed system. A system using a type T can be later extended with DataWriters/DataReaders that publish/subscribe to a type T' that is "different but compatible" according to the rules of XTypes. Old and new DWs/DRs can communicate.
For example, a DataReader<T> can receive T' samples. But the samples you get from that DataReader are samples of type T. So if the DR received a T' data sample containing more fields, the extra fields are stripped out. On the other hand, if T' contained fewer fields, the missing ones in T are default-initialized.
Let me know if you have more questions.
Thanks Alejandro,
A problem I face is that the IDL file has been imposed on us by a government, not even our government! The extensible types would help, but they involve actually changing the IDL, which I am not at liberty to do.
I did try one trick. I took an instance of the largest topic, and
memcpy'd one of the smaller ones into it. I hoped I could just send the big one containing the smaller one as its payload. Obviously the field types and boundaries of the two didn't match, so the fields in the big one contained random data. For most fields this doesn't matter, but for enumerations it does matter. When I tried writing the (big) topic, DDS rejected it because one of its fields was an enumeration of 4 values. The data in the superimposed payload didn't match this and the field was overwritten with an out-of-range value.I thought DDS would just transport topics. Alas I found that it actually validates the data it sends. Just what I didn't need - a transport mechanism that is too smart by half!
So far I have been unable to fool DDS. Can you suggest a way round this?