I've just checked-in the latest attached patch.
this one does neither includes the STATIC lib trick
nor the LogicalTimeDouble class.

Some remarks concerning modifications I did include myself before check-in:

- try to avoid mixin C style include and [new] C++ style ones.
  #include <math.h>
  should be
  #include <cmath>

- size_t is usually unsigned so beware of
  comparing "int" with "size_t".
  Most of the time you'd better use <cstdint> types
  uint8/16/32/64 and int8/16/32/64
  I did add the appropriate definitions in
  RTI/SpecificConfig.h

- you may use STL algorithm std::for_each
  http://www.cplusplus.com/reference/algorithm/for_each/
  for deleting all point stored in a container.

  Declare:

  template <class T>
  struct deletor {
     void operator() (T* e) {delete e;};
  };

  then use:
  struct deletor<whatevertype>  deletorWhatever
  std::vector<whatevertype*> c;
  ...
  std::for_each(c.begin(),c.end(),deletorWhatever);

(file #20661)

Hi Jeroen,

Thank you for all the updates.
I'll try to process them today
and will keep you informed of what is merged and what is not.

Concerning the test modules,
I'll put them in HLA_TestsSuite myself.

I'll have a tight look at the static lib solution.

Alternate logical time may be useful, we'll see
if we should keep such thing in CERTI
(built-on FedTime lib or as a separate lib)
and/or propose a separate module (like python binding etc...)

Hello Eric,

Things are going quite well on this side. We've completed the RTI1516 services we require and are now moving our original project to make use of CERTI.

We've partially tested the services we've ported, but we won't be testing all of them, because of budget constraints.

I'll fill in the spreadsheet tomorrow, along with a new version of the RTI1516 modules.

During the port of our project, I'm sure we will find some additional stuff in Certi that needs porting/fixing, so we're not completely done yet. :)

After this I'm not sure yet how things will go for me personally (with regard to new projects), but if I have the time, I'll put in some work to 'round off' the work we did for CERTI. (I.e. better responses for the test cases, using correct .cc/.hh files, etc.)

I have attached table with all IEEE 1516 services.
The goal is to know which service is already implemented and what remains to do.


(file #20423)

Hello Eric,

Thanks for the feedback.
1) __declspec on Win32 only - I'll keep it in mind. I think we skipped it at first because we were trying to get it to work.

2) throw declarations should match - Good call on that. Unfortunatly VS doesn't warn us about that. I'll see if I can easily get GCC to compile it under Cygwin. At least for the warnings...

3) Add messagetypes/enums at end - I can see how that's required for backwards compatibility. I'll do that from now on.

4) Move tests to HLA_TestSuite - For now I think I'll keep them in the 'certi' part. If I'd move them to the 'applications/HLA_TestSuite' they would end up in a different VS solution, meaning I would have to open two VS instances... Near the end of development I will definetly move them there.

5) Commit HLA1516 to CVS - Thanks! I hope people have a chance to experiment a bit with it... Perhaps I can add the RTI1516Test as a seperate Zip here so people can take a look at the tests.

6) fixed bugs Interaction publish/subscribe - Yeah, it would have been better to report that as a bug, with a patch for a fix. I have just uploaded a patch for another bug I found... (waitForMessage deadlock on exception). I'll keep doing that for any bugs I may find.

7) Warnings on handles - It seems the derived handles override the base 'operator=' operator. I actually think the base does not need the 'operator='... I'll take a look into it.

8) Double macro definition in RTI1516fedtime.h - I added that part because the VS 'IntelliSense' kept insisting it was defined as import, while it should export. Removing the macro still allowes it to compile, so I'll remove it.

The merge went fine, so we'll continue development today. :)

Ok thanks,

Currently testing on Linux.

Hello Eric,

Glad to see you're back. :)
I will commit a new version for you tomorrow.

So far, things are progressing quite well, with a lot of the services ported directly to HLA1516...

I've also been working on a unit test system, which already identified some issues in the RTIA/RTIG code... So far, the unit tests still require manual handling, but I'm certain it could be adapted to be automatic, making it more useful in general.

Thanks for keeping us informed, Eric. :)

Things are going quite well here. Services are being implemented, and I have started working on some unit tests. So far only found bugs in the rtia/rtig, so I guess that's good. :)

Enjoy your trip, and we'll see where we stand in a week.

Hi Eric,

I'd be happy to have some (more) help. :) Let me know if/when he needs any info.

I've uploaded a new patch of my work so far. Unfortunatly I have had to make a 'branch' of some of the HLA1516 header files, in order to get the project compiling under Visual Studio. I've renamed them with a 'certi' prefix, and added an explanation in the file. Still trying to figure out a better way to solve this though.

Right now I'll start working on CERTI being able to parse HLA1516 FOM files. My collegue in the mean time will work on implementing the rti1516::handles and porting the various services.

Hi Jeroen,

Here is a first feedback on your work.

1) I think you don't have to modify
   include/RTI.hh
   Unless I'm wrong
   the appropriate include for 1516 is: include/RTI/RTI1516.h
   and you should probably make CERTI specific
   modifications inside
   include/RTI/SpecificConfig.h

2) I don't think we need separate RTIA for 1.3 and 1516
   the same RTIA should be able to handle both because
   RTIA is only processing internal CERTI messages.

   There may be 1516/1.3 specific messages but I think
   we should try to keep RTIA unique. It will be far easier
   to maintain.

3) libRTI1516
   Following the same idea I'll put 1516 and 1.3 files in the
   same libRTI directory.

   In fact you can modify the existing libRTI/CMakeLists.txt
   in order to compile libRTI1516 using same
   files as 1.3 (if they can be kept common 1516 - 1.3) or
   a separate new file (as you already did).
   i.e there may be
     RTI_LIB_SRCS         RTI_LIB_INCLUDE
     RTI13_LIB_SRCS       RTI13_LIB_INCLUDE
     RTI1516_LIB_SRCS     RTI1516_LIB_INCLUDE

   and then
     ADD_LIBRARY(RTI ${RTI_LIB_SRCS} ${RTI_LIB_INCLUDE} ${RTI13_LIB_SRCS} ${RTI13_LIB_INCLUDE})

     ADD_LIBRARY(RTI1516 ${RTI_LIB_SRCS} ${RTI_LIB_INCLUDE} ${RTI1516_LIB_SRCS} ${RTI1516_LIB_INCLUDE})

    I think you get the idea.

4) Please keep the same naming convention for file extension

     C++ header  = .hh
     C++ body    = .cc
    
5) I did merge-in your modifications of certi.hh


  

Hi Eric,

As indicated on the mailing list, I have taken up this task. Can you assign it to me here? Thanks.

Kind regards,

Jeroen v. IJperen (vyperx)
TASK24