Question

I’m exporting some c++ classes to Lua with SWIG. I have declared boost::filesystem::path in the SWIG interface file like this:

namespace boost
{
    namespace filesystem
    {
        class path {};
    }
}

Now I want to call a function declared in a lua script which should take a boost::filesystem::path& as parameter to pass it to another object. I only need to be able to pass the path to the object. I don’t need to use any functionality from the path object.

function on_path_selected(the_path)
    another_object:set_path(the_path)
end

I am going to call the Lua function from c++ using it’s index.

lua_rawgeti(L, LUA_REGISTRYINDEX, m_function_index);
lua_push[SOMETHING](L, path_object); // <-- HOW TO ?
lua_pcall(L,1,0,0)

THE QUESTION: How to push a boost::filesystem::path as a parameter to the Lua function?

Answer 1

This is actually fairly complicated. The expected use of SWIG is to create modules for Lua. The Lua script should be the one deciding what gets called and what doesn’t. It isn’t really meant for embedded use, where you use SWIG to expose some C++ objects and then call Lua code directly from your application.

That’s not to say that it’s impossible, just complicated.

All SWIG-based C++ objects are passed through Lua as pointers. Thus ownership is a question; you can’t just shove a pointer to a stack object into Lua.

The safest way to do this is to pass a new copy of the object to Lua. That way, Lua owns the pointer. SWIG will know that Lua owns the pointer, and will attach a proper garbage collection mechanism to it to clean it up. So everything should be fine, memory wise.

But doing this requires properly "boxing" (for want of a better term) that object the way that SWIG wants it done. This requires using certain SWIG macros.

Given how you have bound the path type to SWIG, you would do something like this to stick it onto a Lua stack:

swig_type_info *pathType = SWIG_TypeQuery("boost::filesystem::path *");
boost::filesystem::path *pArg = new boost::filesystem::path(the_path);
SWIG_NewPointerObj(L, pArg, pathType, 1);

SWIG_TypeQuery fetches the type of any object that has been bound by SWIG to Lua. This type info object is needed for SWIG_NewPointerObj, which takes a pointer to that type. Both of these are macros. SWIG_NewPointerObj gives Lua ownership of the pointer; Lua’s garbage collector will delete it thanks to SWIG’s metatables. Also SWIG_NewPointerObj pushes the object onto the lua_State stack.

Once it’s on the stack, you can pretty much do whatever you want with it. Return it from a function to Lua, pass it to a Lua function as an argument, stick it in a global variable, etc. It’s a Lua value.

Now, if you type this code into your project, odds are good that you’ll get a compile error when the compiler sees swig_type_info. This type is defined internally within the source file generated by SWIG’s command-line.

You have two options:

1. Put this source code into the .swig file itself. Yes, really. You can define regular C++ functions there, within verbatum sections (the %{ %} delimited blocks). These functions will be copied directly into SWIG’s generated code. You can access them by putting prototypes in headers. This is the simplest and easiest way to work. This is often used for creating special interfaces, where a pre-existing C++ function isn’t appropriate for a Lua API (or simply doesn’t exist).

2. You can generate an appropriate header that contains these definitions with the -external-runtime argument. This has to be a different SWIG execution step from the step that generates the .cpp file. See, it doesn’t actually process the SWIG file or anything. All it needs is the target language (-lua) and whether you’re using C++ (-c++).So just have a command that does swig -c++ -lua -external-runtime someheader.h, and that’s all you need to get the types and macros.

   Include that header in whatever source you want to attach SWIG-bound objects to Lua in.