[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [certi-dev] Complex datatypes
From: |
Eric NOULARD |
Subject: |
Re: [certi-dev] Complex datatypes |
Date: |
Wed, 19 Mar 2008 22:22:32 +0100 |
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