[gme-users] BON Extender Interpreter Problem

[xiong,ming]

Hi, 

   I have figured out the inconsistence. It's kinda complicated. 

 

In my meta-model, I have a ConnectorRef<<reference>> that refers to a
TransConnector<<Atom>> , then, the generated codes regarding to this
dependency looks like this:

XXXXExtension.h

....

class ConnectorRefImpl;

DECLARE_BONEXTENSION2( BON::Reference, TransConnector, ConnectorRefImpl,
ConnectorRef ); 

...

//*******************************************************************

//   C  L  A  S  S   ConnectorRefImpl

//*******************************************************************

class ConnectorRefImpl :

  virtual public BON::ReferenceImpl,

  public TransConnectorImpl 

{

public:

       //

       // ref getters

       virtual TransConnector                  getTransConnector();

 

       ///BUP

       //Class not found

       ///EUP

};

 

 

But when I compiled these codes, the compiler was complaining that:

 

//==========================================================================
=======================

E:\course\GIOTTO_PRJ\Interpreters\GIOTTO\ECSL_DPBonExtension.h(1305) : error
C2250: 'ConnectorRefImpl' : ambiguous inheritance of
'BON::ReferenceImpl::getStereotype'

        C:/Program Files/GME/sdk/BON/BONImpl.h(1077) : see declaration of
'ReferenceImpl'

E:\course\GIOTTO_PRJ\Interpreters\GIOTTO\ECSL_DPBonExtension.h(1305) : error
C2250: 'ConnectorRefImpl' : ambiguous inheritance of
'BON::AtomImpl::getStereotype'

        C:/Program Files/GME/sdk/BON/BONImpl.h(845) : see declaration of
'AtomImpl'

 

Blah, blah blah 

//==========================================================================
========================

As it turned out, TransConnectorImpl inherited from BPM::AtomImpl, which has
the same getStereotype () member function as BON::ReferenceImpl does, which
is how ambiguity happens.(If the getStereoType() of both BON::AtomImpl and
BON::ReferenceImpl are defined in their parent, which is BON::FCOImpl, this
will not happen, because we are using virtual inheritance, which can avoid
"dreaded diomond ")

 

 

So I incorrectly removed the inheritance relation such that it looks like
this:

 

class ConnectorRefImpl :

  virtual public BON::ReferenceImpl,

//  public TransConnectorImpl 

 

And it's compiling, but it violated the compatibility defined previously in
DECLARE_BONEXTENSION2( BON::Reference, TransConnector, ConnectorRefImpl,
ConnectorRef ); 

 

That's why I got the run-time error that says "incompatibility" 

 

The way around it of course could be that we do not generate extender
classes for ConnectorRef<<Reference>>, but what if we wanted to keep this?
How should I change my class structure? Do you or any guys have any idea? 

 

Ming

 

 

 

From: gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Zoltan
Molnar
Sent: Friday, April 09, 2004 2:19 PM
To: 'A list for GME users to share thoughts and discuss bugs and fixes.'
Subject: RE: [gme-users] BON Extender Interpreter Problem

 

Hi,

Could you please send the metamodel (exported into .xme format) the files
are generated from.

 

Till then i could suggest checking you meta-model for corectness by
interpreting it with the MetaGME2004 interpreter and checking the log file
(generated in the same directory as the .xmp file).

 

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 xiong,ming
Sent: Friday, April 09, 2004 2:11 PM
To: gme-users at list.isis.vanderbilt.edu
Subject: [gme-users] BON Extender Interpreter Problem

Hi, GMEers:

  I'm currently using the BON extender interpreter in GME 4 (released on
03/17/2004) to generate the classes and dummy codes for my interpreter. It
compiles perfectly but when I try to launch it from GME, it's giving me an
invalid error. To be specific, it says:

 

Exception Kind: Utils::Exception

Exception Message: Invalid BON Extension class! Check meta-kind
compatibility for HardwareSheet.

 

(Note: HardwareSheet is the model from which the interpreter starts. )

 

I tried other models, and the same exception is raised.

 

I checked the generated file then but found nothing that's not compatible.
Since I didn't change anything in those files and haven't yet inserted my
codes, it seems strange. Then I tried to debug the dll, but as it turned
out, the exception is raised before the program entered InvokeEx, so there's
no way I could track down the bug. 

 

Have you ever encountered similar problems? What could be the possible
course? Need your suggestions badly.

 

 

Thanks

Ming

 

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