Re:Show HN: Another C++ Lua Wrapper
by Doctor_Fegg on Saturday July 04, 2015 @05:54PM
(#9831723)
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.
Re:Show HN: Another C++ Lua Wrapper
by luizpv9 on Saturday July 04, 2015 @09:28PM
(#9832189)
Seems really well done and well documented.
Sorry to ask this without exploring the code myself (!), but there is a check in common.hpp for C++14 compliant compiler. What features of C++14 are you using in this project?
Re:Show HN: Another C++ Lua Wrapper
by TillE on Saturday July 04, 2015 @10:33PM
(#9832314)
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?
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.
Re:Show HN: Another C++ Lua Wrapper
by platform on Sunday July 05, 2015 @12:53AM
(#9832511)
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.
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.
Re:Show HN: Another C++ Lua Wrapper
by pikachu_is_cool on Sunday July 05, 2015 @02:44AM
(#9832746)
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.
Could you explain exactly what yours does differently?
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.
It's a shame, because the library itself is intuitive and reliable, but building it is just painful.