Print

Print


Re: HLA Header Files are not "Set in Stone" (Was: Creating and Destr oying Federations) Keith Snively <a href="/index.htm?LOGON=A3%3Dind0207%26L%3DZ-ARCHIVE-SIW-CFI%26E%3Dquoted-printable%26P%3D247880%26B%3D--%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26XSS%3D3%26header%3D1" target="_parent" >[log in to unmask]</a> <a href="/index.htm?LOGON=A3%3Dind0207%26L%3DZ-ARCHIVE-SIW-CFI%26E%3Dquoted-printable%26P%3D247880%26B%3D--%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26XSS%3D3%26header%3D1" target="_parent" >[log in to unmask]</a>
The changes you state were made, along with another which was removed a lot
of ``define ...`` statements, which specified limits for things like the
number of attributes allowed for a call to update.  However, these changes
had specific reasons and had to be approved by DMSO.  The change I
mentioned along with number 3 you list below presented real problems to
federate developers.  Without RTI_USES_STD_FSTREAM federate developers
would always wind up with the pre C++ `98 iostream implementation
(iostream.h instead of iostream).  The defines I mentioned were specific to
an early RTI implementation and were never used by RTI-NG, and hence set
arbitrary and misleading limits.

The change you mention in number 1) facilitates a more straight forward and
more intuitive mechanism of printing exceptions.  If you catch and
exception as a const reference, which is generally recommended, it is more
intuitive to print it using:

   cout << ex << endl;

as opposed to:

   cout << &ex << endl;

Furthermore, depending if you set up your include statements right, the
second statement may just print out the address of the exception, which
tends not to be very helpful.  The first statement would simply fail to
compile in that instance, which is better than trying to catch the error at
run-time.

The final change you mention, changing RTI to a namespace from a class, is
a good example of just how hard it can be to change the header files.  The
rational for the change was simply that RTI is used like a namespace ...
not a class.  You do not instantiate an object of type RTI and by making it
a namespace, classes contained in it, such as RTI::Exception, can be
forward declared.  This change also does not present any problems with
compile-time compatibility with older implementations.  RTI was originally
a class simply because not all compilers would support a namespace, namely
Sun SPRO4.2, which was widely used at the time.

However, this change was protested by other RTI developers, and as a
result, has been forced back to being a class.  Certainly, any RTI
implementation which attempted to add methods to RTIambassador which draw
equally strong protests.  Run-time link compatibility seems to be required
for RTI 1.3 implementations, and new methods would certainly break that.

The header files may not be set in stone, but they are in some fairly well
dried concrete. ; )

Keith


At Saturday 02:47 PM 7/20/2002, you wrote:
>Nathan, and the rest,
>
>In working with RTI developers, I was also left with the impression that the
>HLA header files were ``set in stone``.  In fact some of the RTI developers
>that I have worked with were forced to use some rather unconventional
>constructs in their code rather than modify the DMSO-supplied C++ headers.
>I was told that this was because ``DMSO required it for certification``.  At
>any rate, this does not appear to be the case now.  Three cases come to
>mind:
>
>         1)  A streaming operator, that takes a reference to an exception
>(rather than a pointer to an exception), has been added to the DMSO RTI
>         2)  RTI was changed from a class to a namespace in the DMSO RTI.
>         3)  A define for RTI_USES_STD_FSTREAM was added to the DMSO RTI
>
>None of these changes are reflected in the 1.3 spec at:
>https://www.dmso.mil/public/library/projects/hla/specifications/c_api_annex.
>pdf
>
>Although I think these are positive changes to the interface, they *have*
>required us to modify code to ensure portability between RTI
>implementations, and indicate that there is a process in place to modify the
>headers (albeit unknown to me).
>
>Steve
>
>Steven R. Drake, Software Engineer
>Modeling & Simulation Technology, Phantom Works
>Office: (256) 461-5771 Fax: (256) 461-2983
>
>The Boeing Company
>499 Boeing Blvd. MC JR-80
>P.O. Box 240002
>Huntsville, AL  35824-6402
>
>-----Original Message-----
>From: Keith Snively [mailto:[log in to unmask]]
>Sent: Friday, July 19, 2002 3:28 PM
>To: SISO - Run-Time Infrastructure and Communications Forum
>Subject: Re: Creating and Destroying Federations
>
>
>At Friday 04:16 PM 7/19/2002, you wrote:
>
> >``Barclay, Nathan`` wrote:
>
>
>These header files are unfortunately set in stone, rather than simply
>requiring compile-time compatibility.
>
>Keith Snively
>Dynamic Animation Systems
>http://www.d-a-s.com
>SAIC:(703)333-5432,
>DAS:(703)503-0500
>FAX:(703)425-2204

Keith Snively
Dynamic Animation Systems
http://www.d-a-s.com
SAIC:(703)333-5432,
DAS:(703)503-0500
FAX:(703)425-2204


To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=Z-ARCHIVE-SIW-CFI