Nice catch Petr,

I did personnally had a look without finding.
How can compiler be such a fool!!

I'm ok with your solution which seems ok
besides the fact that we'll need to forward
call to embbeded class.

From a pure design point of view it may even
be a better solution for libRTI class not to
inherit from std::<Container> class, this
way we can only expose the appropriate interface.

Note that some do already do this with
"protected" inheritance instead of "public" inheritance.

Seems it doesn't work with VC9. It's caused by something in RTItypesImp.hh, but don't have any details yet.

Thanks for merging the patch, Eric.

Is there a reason why some throws in libRTI/RTIfedTime.cc were disabled?
My compiler warns about non-void function witghout a return value.

Index: libRTI/RTIfedTime.cc
===================================================================
RCS file: /sources/certi/certi/libRTI/RTIfedTime.cc,v
retrieving revision 3.1
diff -r3.1 RTIfedTime.cc
49c49
<       throw RTI::InvalidFederationTime("Could not cast to RTIfedTime");
---

>         throw RTI::InvalidFederationTime("Could not cast to RTIfedTime");

73c73
<         throw RTI::MemoryExhausted("Cannot allocate RTI::FedTime.");
---

>         throw RTI::MemoryExhausted("Cannot allocate RTI::FedTime.");

85c85
<         throw RTI::MemoryExhausted("Cannot allocate RTI::FedTime.");
---

>         throw RTI::MemoryExhausted("Cannot allocate RTI::FedTime.");

Here comes a patch against
br_DEV_NoCircularRef branch

which makes it compiles on Windows with MinGW.

I still have the link error with Visual Studio Express 9.
I think this is a bug with some kind of STL issue with
this version.

I'll try the patch on Linux and then merge back
to HEAD.


(file #17383)

All files are checked-in.

My configuration: Windows XP and Visual Studio 2005.

Sometimes the problems disappear when I re-run CMake, e.g. do "clean cache".

Nice work.
I'll have a look and get a try too and
may be we can merge the change into HEAD afterwards.

Happy New Year, Eric!

the latest sources are in CVS (under that branch), but...

I just realized that I fixed only the libFedTime -- libCERTI circular reference.
The libFedTime -- libRTI circular reference is still there. It's the same old story: RTI::xxx need to create the FedTime and FedTime needs the RTI::exceptions.

> I do not insist on my solution.

Don't worry patches and discussion are welcome.

> I was just uneasy about blowing off the CERTI-Win32 port and
> delaying the fix due to other tasks. :-(

I understand that and I appreciate your effort.
However don't blame you,

• I did review your patches.
• CVS version may sometimes be broken on non Unix platform

  this should not last but CVS is CVS this is not a
  version.
 

> I will use the branch and finish my patch.

Ok fine tell me when you are done.

short answer:
 libCERTI should not use RTI::FedTime at all.

If you look at the RTI::FedTime usage structure you will
find 3 majors places:

libRTI because RTI::FedTime appears as parameter
for "time stamped" version of RTIambassador API.
in this case you may use the "abstract" version
because you wont create any  RTI::FedTime object
you get them from the call.

RTIA: here you need the to be able to create
RTI::FedTime object and you may use:
1) the libFedTime directly (no circular ref problem).
2) the RTI::FedTimeFactory::
     2.a) makeZero()
        if you want a constant.
        Note that you may then call
         RTI::FedTime::setEpsilon()
         RTI::FedTime::setPositiveInfinity()
        if you need those constant.

     2.b) decode(const char *)  
       when you received an encoded value from RTIG or Federate.

RTIG: you receive [encoded] timestamped request
      but you need to compute LBTS
      (or other time concerned activity)

      you may use the same method as in RTIA with
      no circular ref trouble either.

The majority of FederationTime usage in libCERTI
should use EncodeFedTime_t opaque type
(for example typedef EncodeFedTime_t vector<char>;)
This is true for Message::fed_time,
Message::lookahead, NetworkMessage::date ...

The only I saw (at the moment :-) is with LBTS.cc/LBTS.hh
which is used in RTIA and RTIG and is currently part of
libCERTI.

I would say that LBTS should be a templated class
taking a TimeType as template parameter which
conforms to the RTI::FedTime API.

Then LBTS becomes a "generic" Time computing algorithm
that may be used (without circular ref) from RTIG and RTIA.
In fact if we want to support user provided time type
every "time manipulating" algorithm should be generically
written using RTI::FedTime API.

From what I have seen it seems doable.

> I assume the RTI::FedTime successor (RTIfedTime) has the
> getTime() method and do cast everytime this method is
> necessary. In current CVS this is commonly used method for
> casting to double (that used for computations inside RTIA).

That's precisely the point I think we don't need this.
Casting to double was done for convenience, but from
waht I saw (again until now) every computation may be done
with
RTI::FedTime
or
RTI::FedTimeFactory

APIs.

I'll try to continue along this road a little bit.
However your patch is more pragmatic and is solving
the circular ref win32 trouble so I did create
a branch called "br_DEV_NoCircularRef"
I would suggest you check-in your patch there.
(we may even release a CERTI 3.3.2 using the branch).

Then if I manage to successfully go to the end of my idea
then I'll backport the part of your patch I'm missing.
If I do run out of time or if I fail :-(
then I'll throw my work and merge your branch on the trunk.

What do you think?

> I hope I did not interfere with your efforts.

You did :-).
No just kidding,
I was heading to another way to go for handling FedTime,
but I'm not finished yet...

My primary objective was not to get rid of circular
ref but to support user provided type, which will
frees us from circular ref.

In fact I think time is different from Exception and the like
there should not be a CERTI FedTime and RTI FedTime
because even if we can imagine a portable way
to go from user provided RTI::FedTime to CERTI::FedTime
we cannot build a user provided RTI::FedTime from
CERTI::FedTime.

My idea was to really make the RTI::FedTime an opaque
type for libCERTI.

In fact I think your idea is working because
you assume you have the method.

Double RTI::FedTime::getTime()

but unless I'm wrong this method is not in the HLA
(neither 1.3 nor 1516)

tech remark: Your patch does not compile on Linux
             because of case sensitive FedTime.hh in
             libCERTI/CMakeLists.txt
             which is fedtime.hh on disk.

Do not commit your patch  [yet].
I'll try to get mine to its end :-).

Ok thanks Petr,

I'll go on with the libFedTime dependency.

FederationList.cc has the same catch (RTI::...) issue.
I've attached the file.

I did attach the "whole" patch too just in case it's easier
to apply for others.



(file #16999, file #17000)

The idea of the patch is to be able
to trace ANY exception.

You may
export CERTI_EXCEPTION=X

just as you may
export RTI_EXCEPTION=X

this should work on windows as well too.
Note that in the same way you can monitor
NetworkMessage/Message exchange using

RTIG_MSG=D
RTIA_MSG=A

Nice work,
I should be able to have a look at this tomorrow
and may tackle the FedTime trouble.

No problem,
since you will do it all then :=)

> Avoid any certi:: class to be a child of a RTI:: class.

Yes I agree that what should have been done in the
beginning :=)

> There should be certi::FederateHandleSet, throwing certi::exceptions.
>The RTI::FederateHandleSet should be a wrapper of
> certi::FederateHandleSet, translating the exceptions (and possibly other values).

Yes we may have generic "wrapping/translating" functions
that properly translate
certi::<type> to needed rti::<type> and then you are right
to rti1516::<type>.

This may need some amount of work I gently called
"side-effect", sadly it may not be easily split in sub-task?

Would you have time and will to go into it?

Go ahead any cleaner refactoring is beneficial
unless it would have foreseen side effects.

OK for GAV_aux.c deletion with proper implem' in GAV.cc

Just a side-note.
The current RTI::Exception contains char*
for name and reason.

The drop-in CERTI::Exception replacement
should preferably use a std::string.

> may use certi::Exception, store it to a code in certi::Message
> and the RTIambPrivateRefs::processException may translate that
> code into a RTI::Exception.

That's a valid technical solution,
in fact you do the "translation" at the same
time you "unmarshall/process" the exception.

However there is a side-effect,
all RTI::Exception directly thrown in RTIambassador may be kept
but every RTI::Exception thrown in libCERTI should be replaced
with "hopefully" identically named certi::Exception.

> Any idea how (in an elegant way) avoid the RTI::xxxSet::Create

As far as my find over the source told me we only
use two of them
RTI::AttributeSetFactory::create
RTI::AttributeHandleSetFactory::create

however we can design a generic scheme for avoiding circular ref.

transform every RTI::<WhatEverFactory>::create into
CERTI::<WhatEverFactory>::create

then make
RTI::<WhatEverFactory>::create
simply call
CERTI::<WhatEverFactory>::create

that's pretty much already what have been done in the past
(and probably forgotten since then) because if you
look at:

RTI::FederateHandleSet *
RTI::FederateHandleSetFactory::create(ULong)
    throw (MemoryExhausted, ValueCountExceeded)
{
    return ((FederateHandleSet *) new FederateHandleSetImp());
}

FederateHandleSetImp is belonging to libCERTI
the factory method belongs to libRTI.

With this scheme you use the XXXXImpl constructor when
within libCERTI and use the factory method when in libRTI
(on in a Federate).

I think this is the good way to go.
The RTI factory method usage from within libCERTI is a
mistake probably due to a misunderstanding and
too our very complete design documentation :=)

What is your opinion?

OK my patch should not be enough, now I remember.
We have used the "somehow lazy approach" of
using RTI::Exception inside libCERTI.

All this happens in:
certi.hh

// RTI Shortcuts
typedef RTI::AttributeHandle AttributeHandle ;
typedef RTI::AttributeHandleSet AttributeHandleSet ;
typedef RTI::DimensionHandle DimensionHandle ;
....

and even worse we use the RTI_EXCEPT macro for
defining CERTI internal Exception
later in certi.hh:

// CERTI Exception-derived Exceptions (including deprecated HLA exceptions)
RTI_EXCEPT(FederateNotPublishing)
RTI_EXCEPT(FederateNotSubscribing)
RTI_EXCEPT(InvalidObjectHandle)
RTI_EXCEPT(SecurityError)
...

I think its a bad idea.
We should have certi::Exception within certi.
Then RTIambassador should properly translate
from
certi::Exception to rti::Exception in order to
avoid the circular dependence alltogether.

This a little more work because we need
to replace the:
typedef RTI::AttributeHandle AttributeHandle ;
with something like a macro
CERTI_EXCEPTION(AttributeHandle)
and write a not so beautiful function/switch
which makes RTI::Exception out of any CERTI::Exception.

This may need some python scripting :-)
However I think it would be much better after that.

What is your opinion?
Should this solve the circular ref?
Do you find it's a good solution?

Even a small change can cause big troubles, so it did.

To compile under Windows, the involved DLL must have no circular dependencies. CERTI now does.
libRTI-NG: exports RTI:Exception, imports certi::Message and certi::Exception;
libCERTI: exports certi::Message and certi::Exception, imports RTI:Exception

Perhaps we need some more symbol shifting? BUT! The RTIA--Federate socket communication uses common classes, that are used from both libRTI-NG and libCERTI. The circular dependency is unavoidable.

I guess the only solution is to put some symbols into a static library and use it from both libRTI-NG and libCERTI.

What do you think should go into that static library?
 - the symbols we just moved, i.e. RTI::Exception and RTI::...Set::Create()
 - the certi:: exceptions, certi:: Message and the SockUN communication
 - or something else?