From: sdflemin <sdf...@cs...> - 2005-01-03 02:42:02
|
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. // THE METAPROGRAM ///////////////////////////////////////////////////////////// // File: My_Meta.mc #include <iostream> #include <mop.h> using namespace std; char* const SYNC_CMOD = "my_meta"; class My_Meta : public Class { public: My_Meta() : Class() {} My_Meta(Environment* e, char* name) : Class(e, name) {} My_Meta(Environment* e, Ptree* name) : Class(e, name) {} static bool Initialize() { RegisterMetaclass(SYNC_CMOD, "My_Meta"); return true; } Ptree* TranslateMemberCall(Environment* env, Ptree* object, Ptree* op, Ptree* member, Ptree* arglist); }; Ptree* My_Meta::TranslateMemberCall(Environment* env, Ptree* object, Ptree* op, Ptree* member, Ptree* arglist) { TypeInfo member_type; if (!env->Lookup(member, member_type)) { // <---- LOOKUP ATTEMPTED HERE!!!!!!! ErrorMessage(env, "environment cannot find member: ", member, member); exit(1); } member_type.Dereference(); ... } // THE BASE-LEVEL PROGRAM ////////////////////////////////////////////////////// // File: base_level.cpp #include <iostream> using namespace std; my_meta class Foo { public: Foo() {} void foo_do_it() { return; } }; class Bar { public: Bar(Foo* a_foo) : my_foo(a_foo) {} void bar_do_it(); private: Foo* my_foo; }; void Bar::bar_do_it() { my_foo->foo_do_it(); // <----LOOKUP FAILS ON THIS LINE!!!!!!!!!!!!!!!!!!!!!!!! } int main() { Foo* a_foo = new Foo; Bar* a_bar = new Bar(a_foo); a_bar->bar_do_it(); ... } // COMPILATION OUTPUT ////////////////////////////////////////////////////////// occ2 -c My_Meta.mc -o My_Meta.o In file included from My_Meta.mc:5: /.../include/mop.h:19:2: warning: #warning "header <mop.h> is deprecated, use <opencxx/mop.h>" g++ -o my_occ My_Meta.o -L/.../lib -locc -lltdl ./my_occ -c base_level.cpp [MetaclassRegistration(My_Meta)] [Class::RegisterMetaclass(my_meta,My_Meta] EXECUTING: g++ g++ -D__opencxx -E -o base_level.occ -x c++ base_level.cpp ---> base_level.cpp:34: environment cannot find member: foo_do_it //////////////////////////////////////////////////////////////////////////////// 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... 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. Any pointers you can give me would be great, and also, is there a document that describes the OpenC++ source design? 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. |
From: Grzegorz J. <ja...@ac...> - 2005-01-03 09:23:49
|
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 |
From: Scott D. F. <sdf...@cs...> - 2005-01-03 21:32:39
|
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 > > > |
From: Grzegorz J. <ja...@ac...> - 2005-01-04 11:21:56
|
Scott D. Fleming wrote: > > 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: [...] > > 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. I am afraid I don't see any easier solution. OpenC++ is missing the functionality you describe. Would like to implement this piece? (Perhaps not with all corner cases at first, e.g. omitting conversions simplifies a lot.) BR Grzegorz > 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 >> >> >> >> > > > ------------------------------------------------------- > 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 |