certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] libFedTime together with a shared libCERTI under Windows


From: Eric Noulard
Subject: Re: [certi-dev] libFedTime together with a shared libCERTI under Windows?
Date: Thu, 27 Nov 2008 21:47:23 +0100

2008/11/27 Gotthard, Petr <address@hidden>:
> Hi Eric, hi All,
> can we ever have a standard compliant libFedTime together with a shared
> libCERTI under Windows?
>
> Fact 1: Windows hates circular references in shared libraries (DLL).
>
> Conclusion 1: As libRTI needs to communicate with RTIA, it needs a
> communication library (libCERTI).

Yes we have libRTI which depends on libCERTI.

> Fact 2: The (unbelievably complex) RTI::FedTime concept uses an abstract
> class in the RTI:: namespace that is supposed to handle time calculations.
> This class is user-provided and has no method to extract a float/double
> value. In IEEE 1516.1 this is yet more complex, as we can have either an
> integer- or a float-based time.
>
> Conclusion 2: The absence of cast to float/integer suggests that the RTI::
> functions are meant to use this class directly.

Yes the Federate and RTIambassador class should use this library thus
the user application depends on libFedTime.

libRTI does not depends on libFedTime since libRTI shoud use abstract
RTI::FedTime
libFedTime does depends on libRTI since it inherits from RTI::FedTime.

Federate depends on libRTI and libFedTime
and libFedTime depends on libRTI.

> As the RTIA must use RTI::FedTime (or rti1516::LogicalTime), it must use the
> RTI::Exception, so it needs libRTI.

OK RTIA should use "opaque user-provided type" RTI::FedTime

thus RTIA depends on libFedTime  (and thus indirectly on libRTI)
RTIA depends on libCERTI for communication

>
> libRTI needs libCERTI, but also libCERTI needs libRTI

No it is not mandatory.
We should "only" avoid to use libFedTime from within libCERTI.

I think that's why you find the methods:

virtual int encodedLength() const = 0 ;
virtual void encode(char *) const = 0 ;

in abstract class RTI::FedTime
when RTIA needs to handle time he should encode the Time in a char* buffer.
"Normally" since the Time handling management is done in the RTIA
(and not in the RTIG) the RTI::FedTime value given by a Federate
to RTIA should flow encoded as char* from one RTIA to another.

Thus ONLY the RTIA **application** should depends on RTI::FedTime.
All other functions found in libCERTI should handle the time as an
opaque "char* buffer".

I've just followed the flow of an UAV with time and looks really like
the time is not
used but in RTIA.

> If my conclusions are not wrong, we cannot have compliant RTI::FedTime, use
> shared CERTI under Windows and avoid circular references. Do you see
> something what I don't?

I think we can (unless I forgot something) but there may be a lot of
modifications.
Thus the Pierre question some time ago:
  Are we ready to use user provided libFedTime :=(

I would say no without some amount of work.

-- 
Erk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]