5 ms·

Show HN: Another C++ Lua Wrapper

24 points by vapourismo 11y ago

Doctor_Fegg 11y ago
Looks interesting. I've recently released a C++ project that embeds Lua (https://github.com/systemed/tilemaker 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 11y ago
  Hope it works for you - love to hear some additional feedback.
  - luizpv9 11y ago
    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?
    - arkadiyt 11y ago
      Yes, there is a check - it's the very first thing: https://github.com/vapourismo/luwra/blob/master/lib/luwra/common.hpp#L12 https://github.com/vapourismo/luwra/blob/master/lib/luwra/co.... Can't speak as to what features of C++14 are being used.
    - moonchrome 11y ago
      From what I can see (quick glance) he uses integer_sequence https://github.com/vapourismo/luwra/blob/56a566dd9e20fc7e3c97baf2b0d3eb108d75dce1/lib/luwra/types.hpp#L271 https://github.com/vapourismo/luwra/blob/56a566dd9e20fc7e3c9...
      - vapourismo 11y ago
        Also variable templates, which are crucial to generating the metatable name for user types.
TillE 11y ago
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?
- dman 11y ago
  Could you elaborate on common deficiencies? What does Luabind get right? What are its shortcomings?
  - Doctor_Fegg 11y ago
    Luabind is terrible to install. The most up-to-date version (https://github.com/rpavlik/luabind 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.
- platform 11y ago
  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.
- vapourismo 11y ago
  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.
pikachu_is_cool 11y ago
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.

24 points by vapourismo 11y ago

Looks interesting. I've recently released a C++ project that embeds Lua (https://github.com/systemed/tilemaker 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 11y ago
Hope it works for you - love to hear some additional feedback.
- luizpv9 11y ago
  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?
  - arkadiyt 11y ago
    Yes, there is a check - it's the very first thing: https://github.com/vapourismo/luwra/blob/master/lib/luwra/common.hpp#L12 https://github.com/vapourismo/luwra/blob/master/lib/luwra/co.... Can't speak as to what features of C++14 are being used.
  - moonchrome 11y ago
    From what I can see (quick glance) he uses integer_sequence https://github.com/vapourismo/luwra/blob/56a566dd9e20fc7e3c97baf2b0d3eb108d75dce1/lib/luwra/types.hpp#L271 https://github.com/vapourismo/luwra/blob/56a566dd9e20fc7e3c9...
    - vapourismo 11y ago
      Also variable templates, which are crucial to generating the metatable name for user types.

TillE 11y ago

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?

dman 11y ago
Could you elaborate on common deficiencies? What does Luabind get right? What are its shortcomings?
- Doctor_Fegg 11y ago
  Luabind is terrible to install. The most up-to-date version (https://github.com/rpavlik/luabind 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.
platform 11y ago
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.
vapourismo 11y ago
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.

pikachu_is_cool 11y ago

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.