News for hackers. Stuff that matters.
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 vapourismo on Saturday July 04, 2015 @06:07PM (#9831753)
Hope it works for you - love to hear some additional feedback.
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 moonchrome on Saturday July 04, 2015 @11:53PM (#9832436)
From what I can see (quick glance) he uses integer_sequence https://github.com/vapourismo/luwra/blob/56a566dd9e20fc7e3c9...
Re:Show HN: Another C++ Lua Wrapper by vapourismo on Sunday July 05, 2015 @07:24AM (#9833195)
Also variable templates, which are crucial to generating the metatable name for user types.
Re:Show HN: Another C++ Lua Wrapper by arkadiyt on Saturday July 04, 2015 @10:00PM (#9832257)
Yes, there is a check - it's the very first thing: https://github.com/vapourismo/luwra/blob/master/lib/luwra/co.... Can't speak as to what features of C++14 are being used.
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 dman on Sunday July 05, 2015 @12:21AM (#9832471)
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.

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.