• 15
• 15
• 11
• 9
• 10

Integrating Lua: Open function calls or wrapper?

This topic is 4032 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hi, I am currently integrating Lua into one of my projects. This mainly uses Luabind. For those who have experience in implementing scripting: Do you litter your code with open lua calls (so, for example, use luabind in the same way you might use the STL), or use a facade class to provide a "ScriptManager" interface for all Lua calls? There seem to be conflicting issues. For example, calling a function using luabind uses: template <class Ret> Ret call_function(lua_State*, const char*, ...) As far as I am aware there is no easy way to pass ... through to a function call, making implementation of a wrapper function awkward (as it so happens, I had already written my own wrapper for function calls using boost::tuple, which I prefer). Similarly, writing a wrapper for the class definition calls is complex - complexity that is already handleded for you in the luabind libraray. So the trade off appears to be between the complexity / time burden of writing wrappers for existing library functionality; versus the benefits of localization of all the library code, something I have always assumed is seen as a good thing. Any thoughts? Jim.

Share on other sites
Quote:
 Original post by JimPriceFor those who have experience in implementing scripting: Do you litter your code with open lua calls (so, for example, use luabind in the same way you might use the STL), or use a facade class to provide a "ScriptManager" interface for all Lua calls?
LuaBind is the facade. Don't make a hammer factory factory.
Quote:
 As far as I am aware there is no easy way to pass ... through to a functioncall

I'm not sure what you mean by this. Are you having trouble using things like boost::bind with vararg functions?

Share on other sites
Thanks Sneftel.

Quote:
 LuaBind is the facade. Don't make a hammer factory factory.

Yeah, this is what I was starting to feel like. The problem was I started off writing a facade using lua API calls, and then started to integrate luabind after I had already written a fair bit of functionality (plus it was the first time I had really used type-traits on any great scale, so I was all excited). Then, as you say, it started to look like a hammer factory factory.

Quote:
 I'm not sure what you mean by this. Are you having trouble using things like boost::bind with vararg functions?

I was under the impression that this sort of thing wasn't valid code in C++:

int foo(...) {do something with ...}int bar(...) {foo(...);}

Now you are of course either a) You are going to prove me wrong; or b) I am going to look up boost::bind and find all my childhood dreams about ellipses answered.

Thanks,
Jim.

Share on other sites
To pass the ellipses on you can make a second version of foo() which takes a va_list as an argument, and take the va_list from bar(). Some c standard library vararg functions are "overloaded" like this ( in as much as you can overload c, usually the function name prefixed with v, printf becomes vprintf ). I don't know if these functions are part of the standard though.

Would that work for you?

Share on other sites
Well, let's see. You can't exactly proxy varargs functions natively in C or C++, no. (There are ways around this, if the library author gave you them; see, for example, vsprintf.) But when would you want to do this? I can't think of where you'd want to proxy call_function in general, only where you'd want to call it with a specific argument list.

Share on other sites

The issue with ... Sneftel was writing the facade - call_function takes a ... parameter, so if I was writing a facade for luabind I would have needed some way to pass a variable length of parameters to this function - hence in my example above foo could be renamed call_function and bar the facade callthrough.

However, this is all now academic, because I am no longer wrapping the luabind library.

Jim.