Hello, I have been having some difficulty with accessing enumerations inside C++ n= amespaces. I have attached a simple test program which binds C++ code consi= sting of one namespace 'nsa', one class 'Person', and three enumerations 'C= ountry', 'Job', and 'Title', each at different scopes. The class and global= enumberation are both accessible as per the documentation but the other tw= o enumerations are not (see wxluanstest_prog.lua). I have included the binding code generated using wxLua 2.8.4.1 on Fedora Li= nux, using the version of Lua supplied in that package, and wxWidgets 2.8.6= (GTK). Any help would be much appreciated, Darwin Slattery _________________________________________________________________ Get free emoticon packs and customisation from Windows Live.=20 http://www.pimpmylive.co.uk=
On 11/6/07, Darwin Slattery <dar...@ho...> wrote: > > Hello, > > I have been having some difficulty with accessing enumerations inside C++ namespaces. I have attached a simple test program which binds C++ code consisting of one namespace 'nsa', one class 'Person', and three enumerations 'Country', 'Job', and 'Title', each at different scopes. The class and global enumberation are both accessible as per the documentation but the other two enumerations are not (see wxluanstest_prog.lua). There is currently no ability to use namespaces in the bindings and the enums can only go one level deep (MyClassName::MyEnumName). How would you envision it to work? If a %namespace tag was added to the binding generator I suppose that it should generate a table within the main table (the one the bindings are put into) for the next set of items and allow this for any depth level. This would be very awkward to try to put into the current implementation since instead of a flat list of classes with pointers to their member functions, we'd have to add another struct to hold the namespace name and then pointers to the classes, enums, etc in that namespace, and another level of the namespace struct, then the classes, a tree. But, thats not nearly as bad as what would have to happen to genwxbind.lua... However, I think there's an equally good and surely more simple solution. The only drawback is that you have to have an individual set of bindings for each namespace. You set the namespace in Lua and also in C++ like this in the "rules" file. hook_lua_namespace = "wxluanstest.nsa" hook_cpp_binding_post_includes = "namespace nsa" hook_cpp_binding_header_includes = "namespace nsa" -- or here Then the binding generator function wxLuaBinding::RegisterBinding would simply use the existing or create new "." separated tables. The code to do it would actually go at the top of wxLuaBinding::RegisterFunctions. Is there anything about this second way that wouldn't work? I think just setting the namespace in C++ should be enough to set the namespace level to anything for the C++ code to work or am I missing something. I do accept that if classes with the same name exist both in and out of a namespace that the binding generator code needs to call (I don't think it would unless your C++ headers had inline functions with them in it, but you could just prefix :: to get back to the root) there may be a problem. I think I would go out on a limb and say that that'd be a pretty sketchy design and wxLua can't cater to everything. Regards, John
Thanks for your reply.
The approach worked fine but I'd just like to clarify one point. I found th=
at using a hook_lua_namespace of 'wxluanstest.nsa' created a table with thi=
s name in adddition to the 'wxluanstest' table i.e. it did not create an 'n=
sa' table inside the already existing 'wxluanstest' table. I just want to k=
now if this what you expected to happen? I ended up changing the hook_lua_n=
amespace to 'wxluanstest_nsa' so that it wouldn't cause a syntax error in l=
ua.
I also used the following value for hook_cpp_binding_header_includes:
"#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespace ns=
a;"
Thanks again for your help,
Darwin
----------------------------------------
> Date: Wed, 7 Nov 2007 19:01:32 -0500
> From: jla...@gm...
> To: djs...@us...; wxl...@li...
> Subject: Re: [wxlua-users] Problem with enumerations in C++ namespaces
>=20
> On 11/6/07, Darwin Slattery wrote:
>>
>> Hello,
>>
>> I have been having some difficulty with accessing enumerations inside C+=
+ namespaces. I have attached a simple test program which binds C++ code co=
nsisting of one namespace 'nsa', one class 'Person', and three enumerations=
'Country', 'Job', and 'Title', each at different scopes. The class and glo=
bal enumberation are both accessible as per the documentation but the other=
two enumerations are not (see wxluanstest_prog.lua).
>=20
> There is currently no ability to use namespaces in the bindings and
> the enums can only go one level deep (MyClassName::MyEnumName).
>=20
> How would you envision it to work? If a %namespace tag was added to
> the binding generator I suppose that it should generate a table within
> the main table (the one the bindings are put into) for the next set of
> items and allow this for any depth level.
>=20
> This would be very awkward to try to put into the current
> implementation since instead of a flat list of classes with pointers
> to their member functions, we'd have to add another struct to hold the
> namespace name and then pointers to the classes, enums, etc in that
> namespace, and another level of the namespace struct, then the
> classes, a tree. But, thats not nearly as bad as what would have to
> happen to genwxbind.lua...
>=20
> However, I think there's an equally good and surely more simple
> solution. The only drawback is that you have to have an individual set
> of bindings for each namespace.
>=20
> You set the namespace in Lua and also in C++ like this in the "rules" fil=
e.
>=20
> hook_lua_namespace =3D "wxluanstest.nsa"
> hook_cpp_binding_post_includes =3D "namespace nsa"
> hook_cpp_binding_header_includes =3D "namespace nsa" -- or here
>=20
> Then the binding generator function wxLuaBinding::RegisterBinding
> would simply use the existing or create new "." separated tables. The
> code to do it would actually go at the top of
> wxLuaBinding::RegisterFunctions.
>=20
> Is there anything about this second way that wouldn't work? I think
> just setting the namespace in C++ should be enough to set the
> namespace level to anything for the C++ code to work or am I missing
> something.
>=20
> I do accept that if classes with the same name exist both in and out
> of a namespace that the binding generator code needs to call (I don't
> think it would unless your C++ headers had inline functions with them
> in it, but you could just prefix :: to get back to the root) there may
> be a problem. I think I would go out on a limb and say that that'd be
> a pretty sketchy design and wxLua can't cater to everything.
>=20
> Regards,
> John
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now>> http://get.splunk.com/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
_________________________________________________________________
Feel like a local wherever you go.
http://www.backofmyhand.com=
On Nov 12, 2007 5:35 PM, Darwin Slattery <dar...@ho...> wrote:
>
> Thanks for your reply.
>
> The approach worked fine but I'd just like to clarify one point. I found that using a hook_lua_namespace of 'wxluanstest.nsa' created a table with this name in adddition to the 'wxluanstest' table i.e. it did not create an 'nsa' table inside the already existing 'wxluanstest' table. I just want to know if this what you expected to happen? I ended up changing the hook_lua_namespace to 'wxluanstest_nsa' so that it wouldn't cause a syntax error in lua.
>
Right, code has to be added to break up hook_lua_namespace by '.' and
the tables created. I wanted to wait to see if there wasn't some
problem with the C++ side before changing anything. I'll try to get
around to it tonight.
> I also used the following value for hook_cpp_binding_header_includes:
> "#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespace nsa;"
Good, I hoped it was this simple. Just wondering, why do you need
"namespace nsa {}"? Is it because you're not #including a header that
defines it?
Regards,
John
>> I also used the following value for hook_cpp_binding_header_includes:
>> "#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespace=
nsa;"
>=20
> Good, I hoped it was this simple. Just wondering, why do you need
> "namespace nsa {}"? Is it because you're not #including a header that
> defines it?
Yes, I had only put the necessary %include's in the .i file.
Regards,
Darwin
_________________________________________________________________
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
http://www.newhotmail.co.uk=
All done, the current CVS should work. You have to regenerate your
bindings to use it.
The added benefit is that wxLua is now installed like any other
library and you can call "require("wx")" even if you're not using it
as a shared library.
Regards,
John
On Nov 13, 2007 3:34 AM, Darwin Slattery <dar...@ho...> wrote:
>
>
> >> I also used the following value for hook_cpp_binding_header_includes:
> >> "#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespace nsa;"
> >
> > Good, I hoped it was this simple. Just wondering, why do you need
> > "namespace nsa {}"? Is it because you're not #including a header that
> > defines it?
>
> Yes, I had only put the necessary %include's in the .i file.
>
> Regards,
> Darwin
>
> _________________________________________________________________
> The next generation of MSN Hotmail has arrived - Windows Live Hotmail
> http://www.newhotmail.co.uk
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>
That works great.
Thanks,
Darwin
----------------------------------------
> Date: 2007年11月17日 15:22:15 -0500
> From: jla...@gm...
> To: djs...@us...; wxl...@li...
> Subject: Re: [wxlua-users] Problem with enumerations in C++ namespaces
>=20
> All done, the current CVS should work. You have to regenerate your
> bindings to use it.
>=20
> The added benefit is that wxLua is now installed like any other
> library and you can call "require("wx")" even if you're not using it
> as a shared library.
>=20
> Regards,
> John
>=20
> On Nov 13, 2007 3:34 AM, Darwin Slattery wrote:
>>
>>
>>>> I also used the following value for hook_cpp_binding_header_includes:
>>>> "#include \"wxbind/include/wxbind.h\"\nnamespace nsa {}\nusing namespa=
ce nsa;"
>>>
>>> Good, I hoped it was this simple. Just wondering, why do you need
>>> "namespace nsa {}"? Is it because you're not #including a header that
>>> defines it?
>>
>> Yes, I had only put the necessary %include's in the .i file.
>>
>> Regards,
>> Darwin
>>
>> _________________________________________________________________
>> The next generation of MSN Hotmail has arrived - Windows Live Hotmail
>> http://www.newhotmail.co.uk
>>
>> ------------------------------------------------------------------------=
-
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now>> http://get.splunk.com/
>> _______________________________________________
>> wxlua-users mailing list
>> wxl...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>>
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
_________________________________________________________________
Feel like a local wherever you go.
http://www.backofmyhand.com=