Show HN: Another C++ Lua Wrapper

[Doctor_Fegg]

Looks interesting. I've recently released a C++ project that embeds Lua (https://github.com/systemed/tilemaker, a utility to make 'vector tiles' directly from OpenStreetMap data dumps) but installation of Luabind is pretty much the pain point for everyone who's tried it. (bjam? I mean, why?) A header-only library is really tempting.

[vapourismo]

Hope it works for you - love to hear some additional feedback.

[TillE]

If you've written this, presumably you've found something lacking in the other eight billion Lua/C++ bindings (I agree, they all have major deficiencies, such that Luabind remains my "least bad" choice).

Could you explain exactly what yours does differently?

[vapourismo]

I've found that most libraries implement the wrapper around C++ functions in the most terrible way. It ranges from userdata types wrapping std::function objects to wrapping the lua_State, which the users have to interact with themselfs.

Luwra uses inlinable functions and templates almost exclusively. That way (best-case scenario), each wrapped field/method/constructor/function implies only one generated lua_CFunction, which invokes the Lua API to retrieve the values and finally call the wrapped function with them. And all that, during compile-time, which in my opinion is the best part about it.

[platform]

this wrapper seems to be leveraging the new C++ features to provide type-safe attribute maps, while avoiding dependencies on boost (for example, the other popular wrapper, luabind wrapper depends on boost). This is just from my initial reading.

[dman]

Could you elaborate on common deficiencies? What does Luabind get right? What are its shortcomings?

[pikachu_is_cool]

I'm generally not a fan of these Lua C API wrappers because they tend to add a lot of useless syntactic sugar that makes things more complicated... but yours is pretty good, I like the usertypes feature.