Yes, exactly: you have to write little shim functions. I'm pretty sure this was what bdamm was complaining about, and I'm complaining about it too. I took your suggestion to be that there was some way of using the API that avoided this.
There might be no better way of doing it (or maybe there might be - I have no opinion), but that wouldn't in my view automatically make the C API "remarkably excellent", "absolutely painless", nor the sort of thing that you might describe as "as easy as it is" (as were the original claims). It would just make it no more inconvenient than it has to be. Forgive me for not getting overly excited at that ;)
Re:Terra: A low-level counterpart to Lua
by pathsjs on Tuesday December 01, 2015 @05:28PM
(#10659372)
For instance, interfacing with c in factor works like this. You have an internal dsl that allows you to express what the signature of a c function is. It is designed to look like a function declaration in c, but it is actually valid factor. And... that's it! You can now call that function, and some meta programming drives from that pseudo signature all the information to translate values back and forth
Re:Terra: A low-level counterpart to Lua
by sitkack on Tuesday December 01, 2015 @06:23PM
(#10659683)
LuaJIT has http://luajit.org/ext_ffi.html and Python has https://cffi.readthedocs.org/en/latest/ modeled after LuaJIT. The API for Lua is very clean for being magic free, something that cannot be said for the CPython API.
At the end of the day, you will always need to take values, plug them into a function, and return that value back to to the VM if desired.
Lua, Ruby, V8, you name it, they all do it. Are you expecting to magically pass a function and have some metaprogramming do everything for you? I mean this was certainly possible with LuaBind but then you suddenly take on Boost, and any experienced integrator will realize some systems quickly need more control than this.