Loading Game Data with Lua

[Nexus]

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.

[Raincode]

I was able to fix the error with LuaBridge, along with learning to check the issues on GitHub if something isn't working, which is good, so thanks.

I'll be off experimenting with that and soon noticing it's too much for me, until I finally start getting a good grasp of C++, but I am just too curious.

So thanks for the help, I really appreciate people answering all those questions I have

[FRex]

What exactly is 'verbose and error prone' and needs 'abstraction' in Lua C API?
Only thing is that everything has to go through lua_CFunction...

[Nexus]

The Selene developer writes about it in his blog.

The Lua C API doesn't know higher-level concepts such as classes, stateful functions, etc; it provides only the low level interface for maximum flexibility. As a C++ user, you typically don't care about the stack and the way how Lua methods are implemented. Abstraction is the whole point of the C++ bindings.

[FRex]

Translating arguments from one language types to another's is perfectly understandable, especially since Lua is dynamically typed and has no limit on amount of taken and returned variables. Even if you bound it all through 'magic' templates you might need or want to have overloads that depend on type or number or arguments, type checking, ability to throw errors and more than one return. C++ doesn't have any of that, it has to go through a protocol.

Lua by design has no 'classes', you can implement them yourself with metatable very easily but again you'll have to bind every method by hand to match lua_CFunction and it's protocol.
What exactly do you mean by a stateful function?

[Nexus]

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. Sometimes you simply want to map C++ variables, functions and classes to their Lua equivalents. In all these cases, it is much easier to use a C++ binding than the C API; there's a reason why so many people have written one.

"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.

[FRex]

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.
This is what you originally said:

A good binding abstracts from the C interface, so you don't have to learn it.

Why are you so fixated on calling function calls 'implementation details'? This is worst use of the term I've ever seen. You don't have to care one bit how Lua tables, metatables and stack are implemented - you simply call functions that operate on them, but since this is C and avoids any pitfalls of keep ownership the objects are on a stack, not given to you wrapped in a class.
You don't even have to control the types, that is done by implementing functions, in Lua operations will cause errors unless overloaded (so a function expecting a pair of numbers can be given classes that overload all numeric operators) and in C you have a type checking functions that return the variable if it's there or long jump or exception out of the function directly to last pcall (in Lua or C). You actually can even attempt to pcall a nil variable or a table or anything, it'll error out, you don't have to care.
Sanity checks are not default but can be compiled in, since it's quite reasonable to expect a person to fix their code not to try and index a number like if it's a table and so on.
This is like saying loading a sf::Texture is 'implementation detail' why do I have to load texture and make sure it did load, all I want is a picture but evil Laurent is forcing these implementation details on me...
You do not need to know how GC works, how allocator works(you can implement own one, if needed, for better locality or less fragmentation/systemcalls overhead), how tables try to have array and hash part, how strings are interned(although if you use some to index something a lot, then you might want to reference it) and hashed, how coroutines work, how references work(except not to use int indexes in table that you use as reference holder) how anything works really.

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.
(This is a quote, guess the original author)

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.
There are three ways to achieve 'statefulness', is that enough to justify evil C API?

[Nexus]

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.

Of course things are possible with the C API, otherwise no C++ binding could be written on top of it.

A good comparison is SFML and OpenGL. You can't achieve everything OpenGL does with SFML, because... SFML is an abstraction. If abstractions provided all the original features, the whole point of abstracting would be missed. But you can achieve a lot with SFML, and in a much faster and more productive way. I don't recommend the Lua C binding to Lua newcomers for the exact same reason why I don't recommend OpenGL to game development newcomers.

[FRex]

Simply show your chosen binding and how it deals with all features and problems while being easier to use than original C API and not very heavy on the performance or compile times. You keep saying how much better, easier, safer and more generic it is and have not yet named it. Is it LuaBridge?

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:
-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.

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.

[Nexus]

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:
-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.

If you call that fairly easy, the C++ version must be trivial.

You should really read the blog post of Selene I've linked 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.

[FRex]

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?
Here is a C version, half of lines are setup required for other things, lines with x are 'dangerous' like a slightly untame little kitten.

int iwantthreeupvals(lua_State * L)
{
    const int a = luaL_checknumber(L, lua_upvalueindex(1));
    const int b = luaL_checknumber(L, lua_upvalueindex(2));
    const int c = luaL_checknumber(L, lua_upvalueindex(3));
    lua_pushnumber(L, a + b + c);
    return 1; //x
}

int main(int argc, char ** argv)
{
    lua_State * L = luaL_newstate();
    luaL_openlibs(L);
    lua_pushinteger(L, 10);
    lua_pushinteger(L, 20);
    lua_pushinteger(L, 30);
    lua_pushcclosure(L, &iwantthreeupvals, 3); //x
    lua_setglobal(L, "iwant");
    if(luaL_dostring(L, "print(iwant())"))
    {
        std::printf("%s\n", lua_tostring(L, -1));
    }
    lua_close(L);
}
 

Nexus - I'm tired of asking for clarifications of your convoluted statements, you have clear anti C, anti old C++ styles and anti C is ok to mix with C++ biases. Either you provide a clear answer, is C part of API good to know or not, and code examples of where C++ heavily beats C or you stop your raving against C API which had immense work put into it to become this clean.
LuaBridge is apparently not looked after anymore, Selene lacks a tonne of features, the blog post is at some times biased (but still more informative than your raving) and making code look longer in Lua version and omitting details. Slightly longer code in itself is not a downside, if the code is clearer and does one thing at a time as opposed to 5 that Selene likes to do. No other binding has been brough up by you or anyone. Probably none can compete against the fact that Lua:
0. has excellent documentation on itself, book PiL on the langauge and tons of tutorials that focus solely on the C API
1. is manatined
2. is developed (at a snail's pace but still, it is likely not going to die soon), and some bindings go back to 5.1 or 5.0 while Lua 5.3 is in sort of 'testing' right now
3. has a C API that is very clear and with superior feature set to most bindings when not overwhelmingly complex
4. has a C API that happens to largely overlap with one of fastest dynamic JITs - LuaJIT

[eXpl0it3r]

I for one just don't like C APIs and I don't have to "proof" my likings. Is it baised? Yes. Do I care? No.

I can't believe to what extent you're going in defending the C API, but well everyone can spend their time and energy like they want.

[Laurent]

If you have nothing more interesting to do than insulting each other in an endless war, please do it by PM. There were some interesting things in this discussion, too bad you have to be so much aggressive to say it.