[Opencxx-users] Re: Environment::Lookup Question/Problem

[Scott D. F. <sdf...@cs...>]

Hi Grzegorz,
Thank you very much for your prompt response. Your advice was very 
helpful; as you said, I was looking in the wrong environment. 
Unfortunately, my problem has not been completely solved. If the 
function that I want to lookup is overloaded, then Environment::Lookup 
will always report the same version regardless of the arguments to the 
call. I suppose this is because Environment::Lookup simply returns the 
first symbol it finds with a name matching that of the function.

For example, if I have a class with an overloaded member function, like 
this:

   my_meta class Foo {
   public:
     void foo_do_it()      { return; }
     int  foo_do_it(int i) { return i; }
   };

And two calls like:

   Foo f;
   f.foo_do_it();
   f.foo_do_it(99);

Then when the calls are translated, Environment::Lookup always reports 
foo_do_it having a return type of void. Environment::Dump shows two 
versions of foo_do_it, though.

The obvious solution that I see here is to lookup all the possible 
versions of the member function using Class::LookupMember, lookup the 
types of the arguments using Environment::Lookup, and use the gathered 
information to determine which version of the member function was 
called.  Unfortunately, this solution is rather complex as there are a 
lot of special cases to worry about (e.g., automatic type conversion in 
C++, arguments that are expressions, etc.).

Again, any advice you offer towards a better solution would be most 
appreciated.
Thanks, Scott


Grzegorz Jakacki wrote:
> 
> Hi,
> 
> sdflemin wrote:
> 
>>
>> Hi,
>> I have been using OpenC++ for about a year now, and recently ran into 
>> a problem. I am doing member call translations (using 
>> MemberCallTranslate), and I need to know if the member function that 
>> the call is being made on returns void. I find that when the call is 
>> made outside the member's class, the Environment does not contain the 
>> member function's symbol. A stripped-down sample that illustrates the 
>> problem follows.
> 
> 
> I don't have much time to look into it now, but it seems to me that you 
> are looking in wrong environment. Given
> 
>     C x;
>     x->f();
> 
> you should be looking for 'f()' in environment of class C, not in the 
> environment of the call site.
> 
> Given the fact that you are in a metaclass of C, you should be able to 
> get hold on the right environment by calling 'this->GetEnvironment()'.
> 
> Let me know if this does not work, I will have a deeper look.
> 
>> I have used the Environment::Dump function before the Lookup to help 
>> debug this, and sure enough, none of the Foo member functions appear 
>> in the dump. The Foo class does, however...
> 
> 
> Seems right.
> 
>> My question to you: is this behavior a feature that I don't understand 
>> or a bug?
>>
>> If it's a feature, can you suggest a way for me to determine the 
>> return type of foo_do_it() in the TranslateMemberCall() function?
>>
>> If it's a bug, can you suggest a patch? I am happy to patch the 
>> OpenC++ source myself, but it will take me awhile to understand it. 
> 
> 
> It seems that no patch is needed here, but if you would consider 
> contributing your work to OpenC++ there are always bigger and smaller 
> jobs to do in OpenC++, OpenC++Core or OpenC++ website, just contact me 
> for arrangements.
> 
>> Any pointers you can give me would be great, and also, is there a 
>> document that describes the OpenC++ source design?
> 
> 
> See opencxx/doc/architecture.html in CVS.
> 
> BR
> Grzegorz
> 
> 
> 
>> Many Thanks, Scott
>>
>> PS: My thanks to the OpenC++ maintainers. It has been an extremely 
>> useful tool for me, and I am glad that the project is alive and well.
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Opencxx-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opencxx-users
> 
> 
>