Re: [certi-dev] Complex datatypes

[Eric Noulard]

2008/3/18, Gotthard,Petr <address@hidden>:
> Hello,
> could you please confirm my findings: I found that CERTI has only string
> attributes (e.g. in updateAttributeValues). Non-string attribute values
> (float, struct, etc.) need to be converted to string using an
> implementation-dependent mechanism.
> I guess this is in line with HLA 1.3,

Yes it is. HLA 1.3 does not specifying user data encoding.
HLA 1.3 convey "bytes buffer" in updateAttributeValues such that
federates (either producer or consumer) should agree
on encoding scheme themselves.

> so the only possibility how to have a
> good interoperability is to implement IEEE1516.2. I'm right?

IEEE1516 is a possibilty.
(partial) IEEE1516.2 support in CERTI is a planned for 2008
type encoding should be supported.

However you must know that current version of CERTI does not
support heterogeneous federation (even if federate agree on value encoding),
that is a Linux/i86 federate won't interoperate with a Solaris/Sparc one,
there are endianess and alignement issues.

This is the subject of the work (in progress) of task:
https://savannah.nongnu.org/task/?6910

This work introduces a new libCERTI class called MessageBuffer
which may help you to encode/decode data in a portable way.
see:
http://cvs.savannah.nongnu.org/viewvc/certi/libCERTI/MessageBuffer.hh?root=certi&view=markup

The encoding is a CDR-like encoding for which the receiver
must swap byte only if it has different endianess than the sender.

I give more documentation about the class usage as doxygen comments.
You may look at the testcase too:
http://cvs.savannah.nongnu.org/viewvc/certi/test/utility/CertiUtilTests.cc?revision=1.8&root=certi&view=markup

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.

-- 
Erk