Encoding/decoding errors for composite types

[anthonycramp]

(These comments are based on review of the Java code ... a quick review of the C++ seems to point to the same issues).

While implementing HLA1516eVariantRecord I reviewed some of the other encoding helper classes and noted a few cases of deviation from the standard. These issues were constrained to the composite types HLAfixedArray, HLAvariantArray, HLAfixedRecord.

• No padding. In all cases it appears that padding has been ignored (not necessarily a bad thing).
• In all cases the computation of a type's octet boundary is based on the contained types' encoded length rather than octet boundary. However, since the octet boundary is only used for padding, and no padding is implemented, this hasn't been a problem.
• HLAfixedArray encodes the length of the array as the first four bytes although the standard doesn't require this. Encoding the length into the array is only required for HLAvariantArray. This hasn't been a problem since both the encode and decode routines are expecting the length, but it does add four bytes to the sent attribute value.

[anthonycramp]

Adding some extra information here. Code generated using Pitch Developer Studio can use Portico as an RTI but will continue to use their own encoding/decoding helpers. This basically precludes the use of Pitch Developer Studio if those federates are to interact with any federates written to use Portico's implementation of the encoding/decoding helpers (since the encode/decode algorithms don't match). Fault here could go either way: the Pitch Developer Studio generated federates should be sourcing and encoding/decoding helper from the RTI of the day; but, Portico should be doing encoding/decoding in accordance with the standard.