Re:Show HN: Another C++ Lua Wrapper
by vapourismo on Sunday July 05, 2015 @07:38AM
(#9833214)
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.
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.
Could you elaborate on common deficiencies? What does Luabind get right? What are its shortcomings?
Re:Show HN: Another C++ Lua Wrapper
by Doctor_Fegg on Sunday July 05, 2015 @07:01AM
(#9833158)
Luabind is terrible to install. The most up-to-date version (https://github.com/rpavlik/luabind) is nowhere to be found on the first three pages of Google results for 'luabind'. It requires and builds with Boost, with all the attendant package version conflicts - for example, the Luabind package for Ubuntu 14.04 has the two-year-old Boost 1.54 as a dependency, which typically conflicts with newer Boosts from PPAs. And for some reason the github source generates a library called libluabindd.so, with a spurious extra 'd' which requires symlinking to libluabind before stuff will build against it.
It's a shame, because the library itself is intuitive and reliable, but building it is just painful.
Could you explain exactly what yours does differently?