Re: [certi-dev] Complex datatypes

[Eric NOULARD]

Le Wed, 19 Mar 2008 11:09:33 +0100,
"Gotthard,Petr" <address@hidden> a écrit :

> > 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. ;-) 

Ok right I misunderstood that part :-)

> > 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.

Not really certi::MessageBuffer should be seen as an helper tool
implementing encoding method. You may well encode datatype not
using certi::MessageBuffer and still be compatible with
certi::MessageBuffer.

The only "specific" part of certi::MessageBuffer is the 5 reserved
bytes at the beginning of the buffer, 
but you may simply not use (or ignore) that feature.

> > 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;

That right. 
certi::MessageBuffer is missing operator<< implementation
(or operator>>) in order to make it a ostream (resp. an istream)
this is easily doable but not done (yet).

The only thing stupid with stream operation is that they can
be fairly inefficient for array.
I don't want to write a loop of

buf << certi::as(HLAfloat32BE) << A[i];

instead of

buf.write_floats(A,A_size);

> 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).

I will add more comment on this later.

--
Erk