[gme-users] Question regarding BON extender interpreter and"getReferred()"

[Zoltan Molnar]

Matt, you're right. The method names are in conflict (a BonExt'er bug).
 
Robert, please apply the patch by hand as Matt suggested.
 
br, Zoli
 
 
-----Original Message-----
From: gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Matthew
J. Emerson
Sent: Monday, September 05, 2005 10:49 AM
To: gme-users
Subject: RE: [gme-users] Question regarding BON extender interpreter
and"getReferred()"



I made a small example to test out Ace's exact problem. It doesn't
really have to do with the inheritance hierarchy he described -- it has
to do with the fact that the reference has multiple referent types.

In my example, Reference1 can refer to three different types: Model1,
Model2, or Model3. In this case, the BON Extender generates a single a
referent getter method which could return objects of any of the three
types. The offending generated code is:

//BON Extender-generated header file

class Reference1Impl :

        virtual public BON::ReferenceImpl

{

public:

      //

      // ref getters

      virtual BON::Model  getReferred();

      ///BUP

      // add your own members here

      ///EUP

};

//BON Extender-generated source file

BON::Model Reference1Impl::getReferred()

{

      BON::FCO r = getReferred(); //Infinite recursion

      return BON::Model(r);

}

To avoid infinite recursion, the generated source code should have been:

//BON Extender-generated source file

BON::Model Reference1Impl::getReferred()

{

      BON::FCO r = BON::ReferenceImpl::getReferred();

      return BON::Model(r);

}

I think this is a bug in the BON Extender. Zoli, if you want my example
let me know.

--Matt


> -----Original Message-----

> From: gme-users-bounces at list.isis.vanderbilt.edu [mailto:gme-users-

> bounces at list.isis.vanderbilt.edu] On Behalf Of Thompson, Robert C

> Sent: Saturday, September 03, 2005 11:55 PM

> To: gme-users

> Subject: [gme-users] Question regarding BON extender interpreter and

> "getReferred()"

> 

> Hi,

> 

> I have a question regarding BON extender interpreter-generated code
and

> the method "getReferred()".  This is with GME 4.11.10.

> 

> In my metamodel I have a class "A" and a class that references it
"RA".

> RA also inherits from two other classes "B" and "C".  In the

> extender-interpreter generated code, I get something like the
following:

> 

> class RAImpl : virtual public BON::ReferenceImpl, public BImpl, public

> CImpl {

> ...

> public:

>       virtual BON::Model getReferred();

> ...

> }

> 

> Later, in a plugin, if I have an instance named "r" of RA (not
RAImpl),

> I tried this:

> 

> BON::Model m = r->getReferred();

> 

> When I do this, I get an instant death to my GME sesssion, no warning
or

> message, just "poof".

> 

> So, I tried this:

> 

> BON::Model m = (dynamic_cast<BON::ReferenceImpl*>(r.operator->()))

> ->getReferred();

> 

> This gives me the desired behavior.  So basically I have to cast "r"
to

> BON::ReferenceImpl so that I use BON::ReferenceImpl::getReferred
instead

> of RAImpl's version.

> 

> Am I missing something?  I had expected that the RAImpl::getReferred()

> (i.e. the one exposed on the extender-interpreter-generated interface)

> would give me what I wanted...  A wild guess makes me think it's

> something with the virtual inheritance of BON::ReferenceImpl and the

> virtual-ness of RAImpl::getReferred()... because the body of

> RA::getReferred() invokes "getReferred()". But I don't really know for

> sure that this is causing my problem.

> 

> Any help or pointers would be much appreciated.  It can be worked
around

> but I'm confused as to what is the expected meaning/behavior of the

> method that seems to be causing me trouble.

> 

> Thanks

> -ace

> Ace Thompson

> Systems and Software Engineer

> FCS LSI C4ISR Battle Command

> robert.c.thompson3 at boeing.com

> +1 480 891 2284

> The Boeing Company

> 

> 

> _______________________________________________

> gme-users mailing list

> gme-users at list.isis.vanderbilt.edu

> http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.isis.vanderbilt.edu/pipermail/gme-users/attachments/20050906/ac3d1ac9/attachment.htm