Print

Print


Hi Mikael,

Yes, once you set the alignment for a variant record it would be more or less set. It would be like changing the definition of any datatype. Any existing federates, unless they were specifically written to read the FOM and change their encoding/decoding accordingly, would then need to be updated to work with the new datatype. So for increased flexibility in future FOM extensions, I imagine many FOM developers might simply choose to use a 64 bit alignment even if they currently only need 32. However the benefit this gives over option 1 is that the choice is the FOM developer's and not dictated by the standard. If there was no imaginable need for 64 bit alignment, 32 could be used. Or if someone really required 128 bit alignment, that would also be possible.

I don't think we would have to go so far as to disqualify someone from adding an alternative that would normally use a 64 bit alignment when the datatype specified 32. It would then just require the decoder to copy the data out into a structure of the correct alignment rather than accessing it in-place. So it would be less optimal, but still feasible.

Regards,
Aaron

########################################################################

To unsubscribe from the SAC-PDG-RPR list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-RPR&A=1