Select variant based on value in the transport frame about commsdsl HOT 1 OPEN

Unfortunately at its current state the CommsChampion Ecosystem doesn't provide good means to deal with your specific use case.

After some consideration I would advise you to stick with the sequence of the <optional> fields. Although handling the values will require some boilerplate code, but I think it's a lesser evil. Doing what you need with <variant> fields is also possible, but it will require a custom code injection and it is very easy to make it wrong. Such approach will just move complexity and "manual" boilerplate code from one place to another, probably even increase it.

Just to give you an idea how to make <variant> based solution work, you need to perform the following steps:

• Make your <variant> field a global one to allow code injection.
• Extend the default field implementation with the .extend file.
• In the extended class there must be an ability to access the transport field stored in the message interface, i.e. there must be an extra pointer to the relevant field in the private data member. When message object is created, the constructor code of the latter needs also to be custom to set the pointer to the transport field.
• There is a need to fully re-implement read() and refresh() member functions ("manual" boilerplate code), similar to what is performed by the code generator (see tutorial4), but instead of reading the "key" field, access the transport field via stored pointer. The refresh() functionality also needs to update the transport field stored in the interface.
• The write() (and probably length()) functionality can be inherited, but will probably require using pseudo keyword on the "key" fields to prevent them to be written during the serialization.

from commsdsl.