lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Miles,

You might just be right, swig is a well tested and used tool and might have proven much better to write the bindings then creating yet another tool. My approach has the benefit that it encourages in code documentation and that generating new bindings takes 5 minutes but that may not be enough to justify the creation and maintenance of another binder. The python bindings for OpenCV are made with swig on the C interface and although the new C++ API for opencv has been around for some time, it is taking time to migrate and that does not seem like SWIG is an agile tool. Finally, the code generated by SWIG is quite unreadable and uses tons of ugly constructs (goto, static_cast ?), but that may be because Python is not as easy to interface as Lua even though I doubt it.

Just as an example, I wanted to catch cv::Exceptions to produce good error messages in Lua. To do this I adapted a single template:

<%= comment(@function) %>
<%= signature(@function) %> {
  try {
<%= indent(body(@function), 4) %>
  } catch (cv::Exception &e) {
    std::string *s = new std::string("<%= @function.id_name %>: failed (");
    s->append(e.err);
    s->append(")");
    lua_pushstring(L, s->c_str());
    delete s;
    lua_error(L);
    // never reached
    return 0;
  } catch (std::exception &e) {
    std::string *s = new std::string("<%= @function.id_name %>: ");
    s->append(e.what());
    lua_pushstring(L, s->c_str());
    delete s;
    lua_error(L);
    // never reached
    return 0;
  } catch (...) {
    lua_pushstring(L, "<%= @function.id_name %>: Unknown exception");
    lua_error(L);
    return 0;
  }
}

This kind of templates (and the generated code) is very easy to maintain. From my point of view, SWIG is a good old 14 years old grandfather that got a little senile over the years ;-). I don't pretend Dub is better (it surely is more buggy), but it lets me work in ways I understand (well documented intermediate models with good introspection capabilities), test-driven development. In fact, if swig was so cool, the Lua bindings for OpenCV would be here for ages and the Python stuff would be totally up to date (and there would not be 3 versions of these bindings).

But maybe my view on swig is too biased and I'm just too stupid to adapt (sincerely).

Cheers,

Gaspard
On Sat, Mar 13, 2010 at 3:42 AM, Miles Bader <miles@gnu.org> wrote:
Gaspard Bucher <gaspard@teti.ch> writes:
> * you have to write receipts
> * you cannot parse the inline C++ documentation to generate the docs
> * it's a compiled piece of code (not that easy to adapt)
> * you have to learn yet another language just for the bindings

Hm, swig's interface definition language is basically C++; you can in
theory just feed it your existing .h files and generate an interface
from them.

In practice you usually don't want to do this, but instead copy the C++
definitions and tweak them a bit for swig.  Among the reason for this:

 (1) Often you don't really want the [Lua/...] interface to be _exactly_
    the same.  You want it to mesh with your target language well, and
    sometimes C++ interfaces don't, and need a bit of adaptation
    (though the bulk of the interface remains identical).

    For instance, C++ doesn't have multiple return values, so a C++
    method may say "void method (int arg, int &result1, int &result2)"
    -- but in Lua, you'd really rather just get result1 and result2 as
    return values.

    In other cases, you'd really rather just suppress a particular
    method in the Lua interface, and replace it with a small shim
    method that better matches Lua (generally these are not really Lua
    specific, but simply more suited to scripting language in general).

 (2) Swig's C++ parser, while decent, isn't perfect, and sometimes needs
    help (e.g., you have to tell it which template instantiations are
    important).

If you have a better parser, I imagine you can maybe avoid (2), but
problem (1) seems somewhat inherent to the task of interfacing
dissimilar languages.  Is doxygen annotation so expressive that it helps
solve this problem?  (doxygen is after all, "another language" :)

-Miles

--
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia