[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [certi-dev] Complex datatypes
From: |
Gotthard,Petr |
Subject: |
RE: [certi-dev] Complex datatypes |
Date: |
Wed, 19 Mar 2008 11:09:33 +0100 |
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