RE: [certi-dev] Complex datatypes

[Gotthard,Petr]

Hi,

> > However, I'd like to drift towards HLA1516, so rather than 
> > enhancing certi::MessageBuffer I'd create a class for each
> > datatype with encode/decode function just like
> > rti1516::LogicalTime. What do you think?
> 
> I think LogicalTime is a special case which may deserve 
> special treatment.

You may be right. However, the encode() and data/size() functions are mentioned 
also by § 12.5.2.4 Handles.

> ... I did precisely avoid one class per-type encoding for
> performance reason. I did not want to create a lot of small objects.

I got your point. Creating objects for float/double types would definitely 
impact on performance. On the other hand the types like HLAfixedRecord will be 
objects anyway, so the performance may not be affected.

> I think this is somehow what is described in 1516-1.2000 
> document at § 12.5.2.4 Handles
> 
> "Additionally, an encode() method is provided that returns an
> encoded form of a handle, RTI_EncodedData...
>
> certi::MessageBuffer is a building block for such operation.

The encode/data/size() methods encode/decode the handle itself. This supports 
my theory that each datatype should have encode/decode functions. ;-)
  
> I don't want to convince you to use certi::MessageBuffer but 
> it was meant to :=)

The certi::MessageBuffer may be a solution for simple types like single/double, 
but I'm not sure how would certi::MessageBuffer handle e.g. the fixed/variable 
records if there were no datatype specific functions?

There is also an disadvantage(?) that every datatype must be coded into 
certi::MessageBuffer.

> In this regard certi::MessageBuffer does not do "specific" 
> encoding it encodes basic types in either host endianity 
> (memcpy) or converse endianity (byte order swap).
> 
> I think this respects the HLA<type><bitsize><endian> type idea?
> What do you think?

There is a nice comment in MessageBody.hh: "shouldn't we use just that need 
strstream?", in our case rather something like strstream.
It may be easier to use. (But also slower.) For example:

float A;
certi::MessageBuffer buf << certi::as(HLAfloat32BE) << A;

> What you can do is to implement somes (say 10 of them) 
> classes as you thought and then we compare what we get together?

Now I'm convinced not to implement special classes for each float/double. I 
will try to find a solution that suits also the fixed/variable records. (This 
is my original motivation; I want to encode AccelerationVectorStruct and other 
structures from RPR-FOM).

> Regarding MAK RTI are you using it? How do you handle the 
> encoding issue?

Personally I'm not using MAK RTI (for now), but need to keep portability.

I've investigated the MAK RTI3.2 evaluation and
 - the MAK RTI uses the DLC HLA1516 API as defined in SISO-STD-004.1
 - there are no encoding/decoding functions for float/double nor for the 
fixed/variable records (this implies encoding/decoding is considered to be a 
user responsibility)
 - the provided examples use no records, the basic types are encoded using 
std::stringstream, e.g.

   stringstream ss;
   ss << "13-" << myUpdateCount++;
   string tagForThisUpdate(ss.str());
   ...
   myAttrValues->add(myAttrHandlesArray[0], tagForThisUpdate.c_str(), 
tagForThisUpdate.length());
   ...
   myRTIamb->updateAttributeValues(myObjectHandle, *myAttrValues, 
tagForThisUpdate.c_str());

My comment: This probably violates IEEE1516.2, but provides at least 
Intel/Sparc compatibility. Just for curiosity I will ask MAK about this issue.

I think I'll need a certi::MessageBuffer (or something similar) that could be 
used with MAK RTI. I'm gonna make a proposal.


Petr