I am aware, that this isn't exactly the right forum, but since I read it in the book, I thought someone must know something.I wrote the quoted passage in the book, and what I had in mind is more or less what I wrote in the last post ;)
A new recent, very nice binding library is Selene (https://github.com/JeremyOng/Selene).This looks really promising. C++11 would allow to simplify a lot of things.
You'd be better off without using a binding for now, many of them do weird things like automatically create metatables and so on, this is really bad if you don't understand what the Lua logic behind that is. It's too much of a headache to try to learn all three - language, C API and binding API all at once.A good binding abstracts from the C interface, so you don't have to learn it. Of course you have to learn Lua (and maybe you get some insights about the C implementation when having a deeper look). But the only sane thing you can do with the C binding is writing another wrapper for it, unless you want to use verbose and error-prone boilerplate code all the time. In terms of productivity, I wouldn't recommend that -- but it may be an interesting experiment.
It also is doing the 'magic' and taking away a lot of power you'd get learning C API. Using Selene's API you couldn't write a function to take advantage of Lua errors or overloading on amount/type of arguments passed without the C API.Selene is very young, so if more features are needed, I would rather choose another binding, there are enough of them. It depends of course on what you need and how much time you want to spend on making C++ bind to Lua.
I'm just saying that if you use C++, you don't always care about the protocol or the implementation details of Lua tables and stacks.No, you are saying you always don't care about the protocol. The switch of word order is important.
A good binding abstracts from the C interface, so you don't have to learn it.
there's a reason why so many people have written one.Unfortunately, no. The spread of a habit doesn't allow direct conclusions about its quality.
Sometimes you simply want to map C++ variables, functions and classes to their Lua equivalents.There are features you can't or don't want to map over, semi often too. I personally didn't map over Vector2i that I used for grid position in my PacMan clone to Lua, I used a pair of numbers instead, way easier and faster. Is there a silver bullet binding library, one that has little overhead, lots of control and doesn't 'lock out' any Lua feature while being simple and easy to use. Name please?
"Stateful function" in the sense of function object that can carry additional data besides parameters. Such as captured variables in a lambda expression, or member variables in a functor class.Lua can overload call operator if you need exactly that, it can also create functions in coroutines that keep local variables to themselves between yields and a C function can have upvalues which are Lua values that the C function can access using C API.
Why are you so fixated on calling function calls 'implementation details'?Not function calls, but big parts of the Lua C API. A truly abstract C++ binding could be written on top of a completely different backend (if there were one), still maintaining the same functionality.
This is like saying loading a sf::Texture is 'implementation detail'No, it's not. You use sf::Texture directly all the time. It's rather like saying "stb_image" is an implementation detail... and yes, it is.
Unfortunately, no. The spread of a habit doesn't allow direct conclusions about its quality.Instead of quoting me out of context, let's stay with the topic. There is a good reason why people write wrappers to abstract from C libraries in general, and the Lua C library in particular -- do I seriously have to explain it?
Is there a silver bullet binding library, one that has little overhead, lots of control and doesn't 'lock out' any Lua feature while being simple and easy to use.There's never a silver bullet, choosing the right tools is always about trade-offs. In my case, I trade simplicity, type safety and genericity for some flexibility. But I'm always able to fall back to the C API in case I really need it, or even extend existing wrappers to fit the gap.
Lua can overload call operator if you need exactly that, it can also create functions in coroutines that keep local variables to themselves between yields and a C function can have upvalues which are Lua values that the C function can access using C API.Yes, and compare the code needed to achieve that with equivalent code using a C++ Lua binding. Count the number of methods you need to know, and the number of places where you have to be extra careful to not make any mistakes.
Not function calls, but big parts of the Lua C API.Such as? Other than the stupid protocol that is quite simple in itself.
There's never a silver bullet (...) But I'm always able to fall back to the C API in case I really need it, or even extend existing wrappers to fit the gap.But you just said via your advice that you 'don't have to learn it(C API)' a while ago because a 'good' binding abstracts it away. While at the same time I said a fair while ago that Selene is extremely fit for a particular purpose and my advice is to learn C API before any binding because that gives understanding of what the binding does, ability to read its code and eases the strain of learning by quite a lot. You are the one talking about silver bullets and completely eliminating an entire aspect of Lua.
Yes, and compare the code needed to achieve that with equivalent code using a C++ Lua binding. Count the number of methods you need to know, and the number of places where you have to be extra careful to not make any mistakes.To use upvalues you need:
do I seriously have to explain it?Yes. Not everything is immediately better in C++ over C. Lots of things are but not everything. I've yet to see harsh criticism of C API and outcry for a 'truly abstract easy safe' binding such as yours, ever. I've instead seen it being compared to other scripts' C interfaces that are apparently worse.
If abstractions provided all the original features, the whole point of abstracting would be missed.Then why do you want a simple and automatic way to bind your code to Lua 1:1? That is a kind of 'binding' and abstraction as well, script is not C++, not all that works in C++ works in Lua, not everything even should.
Sometimes you simply want to map C++ variables, functions and classes to their Lua equivalents.
You are the one talking about silver bullets and completely eliminating an entire aspect of Lua.No I'm not, please read my last post again if you got that impression. I explicitly mentioned that there will be a flexibility trade-off. I haven't measured performance, but I doubt there will be a huge difference, since C++ template metaprogramming and other abstractions don't automatically incur runtime overhead.
To use upvalues you need:If you call that fairly easy, the C++ version must be trivial.
-checkers or getters of your values
-setters of your values
-lua_pushcclosure
-lua_upvalueindex
4 functions in total at a minimum, two used uniquely for that purpose, both easy to graps, and you have to be reasonably careful about what you pass in them or compile with api check, I don't know how extensive the checking is is. It's fairly easy.
No I'm not, please read my last post again if you got that impression. I explicitly mentioned that there will be a flexibility trade-off.Nexus, pick, do you have to or do you not have to learn it? This is YOUR post:
A good binding abstracts from the C interface, so you don't have to learn it.Which one is it? Learn or not?
You should really read the blog post of Selene I've link in an earlier post, it explains exactly what I mean. Code is much shorter and expressive when you use a C++ binding. Again: for a flexibility trade-off.I read it long before this thread appeared. Selene is 10% feature complete, if that. Also, show me the C++ version. Unless there was a commit of VERY significant work, that adds upvalues to Selene in time between now and back when I downloaded it originally, it doesn't have them yet!
C++ version must be trivial.Show the example code or go away with your 'claims'. If the way of the super C++ binding is so easy that using 4 methods is 'much' why did you not produce any so far to enlighten me?