Re: [certi-dev] Complex datatypes

[Eric NOULARD]

Le Tue, 18 Mar 2008 18:04:16 +0100,
"Gotthard,Petr" <address@hidden> a écrit :

> Thank you, Eric,
> 
> > As of current CERTI implementation you may only do 
> > homogeneous simulation such that memcpy should do the job for
> > UAV/RAV. However you may work for teh future and properly encode
> > data either using your own portable encoding scheme, or 
> > certi::MessageBuffer or you may contribute for support 
> > HLAxxxxxBE/LE encoding scheme.
> 
> I'm interested to contribute the encoding/decoding functions to CERTI.
> 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.

I did not have an enough
deep look at RTI1516 API regarding data encoding
but I did precisely avoid one class per-type encoding for performance
reason. I did not want to create a lot of small objects.

MessageBuffer has member method to encode/decode every base types
(signed or unsigned int 8/16/32/62, IEEE-754 float, IEEE-754 double,
 C++ std::string, C char* null terminated string)

When you encode data the buffer is updated (appended) with the encoded 
data. When you are done you may get the (global) size of the encoded
data and a pointer to the raw encoded data in order to use it for
sending in UAV (or CERTI internal messages).

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. RTI_EncodedData has a data() method that returns an
untyped pointer (i.e., a void *) as well as a size() method that
returns the size in bytes (represented as a size_t) of the data
returned by the data() method. A copy constructor and a copy-assignment
operator are also provided."

certi::MessageBuffer is a building block for such operation.
 
> Funny is that even IEEE1516 specifies no functions to handle HLA
> datatypes, so if my federate uses CERTI specific functions to
> encode/decode data, it cannot be any longer used with e.g. MAK RTI. I
> wonder how MAK people solve this problem.

As far as understand it is the responsibility of user to encode data
OR if you tell the RTI that your data is say "HLAinteger64LE" in your
FOM the issue is solved since the RTI knows what to do with the data
as soon as he knows what is the endianity of the host
which is the purpose of
certi::MessageBuffer::HostIsBigEndian
or
certi::MessageBuffer::HostIsLittleEndian

I don't want to convince you to use certi::MessageBuffer but it was
meant to :=)

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?

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

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