Hello.
I am now looking for a good scripting language to use within C++ which will replace the current one (luabind).
Now I will explain why I want to change luabind.
First I like the lua syntax, and the fact it is quite easy to interface it with my development. It is also appreciable to use a scripting language widly adopted in the world.
But I am now fed up with it for these reasons: each time there's a new version of luabind I have many problems with my development: compilation issues, linking issues and running issues (segmentation fault, not running...). For example the last time I could plainly use my program (which uses luabind) was on april. All the next releases I had broken things (out of my concern). It is also worth to add that there are other bad points with using luabind. One of them is that it is not that easy to write object-oriented scripts with it (for example I often have to use temporary variables between commands so that the script works). But I can live with that.
I know there are other C++ bounds from lua (cf http://lua-users.org...indingCodeToLua) but I would like to avoid to have to try them all, mainly if I will encounter the same experiment than I did with luabind.
What I am looking for should not necessary binds the lua language. I am also opened to python. However my last attempt to use python was a disaster, mainly because of the bjam thing which I didn't succeed to make it work (if you know how to manage this, feel free to propose python).
So, to resume this all, I am looking for a good program (library for example) that can easily interface with a scripting language like lua or python, and offers object oriented capabilities (I want to be able to easily use my C++ objects inside the scripts). And most importantly, I want something that won't be broken each times there's an update (I use Linux/Debian Testing, so updates could happen quite frequently), and something I can easily, and bug-freely migrate to other Linux, Windows (and later Apple) machines without having harms because of incompabilities due to versions/systems...
I hope you could help me find the rare pearl.
Thanks for the read.
Robsut C++ bound scripting language
It's not what you're looking for, but you could consider manually writing your Lua API, instead of using a library to automate it. The author of the BitSquid engine tries to justify this approach by arguing that you'll end up with a more Lua-centric API if you do it this way:
we actually write all our Lua bindings by hand (i.e., explicit int do_something(lua_State *L) functions).
[size=2]It is just a few lines of code for each function you bind, so it doesn't take much time and I find that being deliberate about what you export to Lua and how leads to better Lua APIs -- smaller, simpler and more Lua-style than C-style. It also means we can refactor the C code without affecting the Lua API.
[size=2]I used to do automatic Lua bindings in the past (with template matching), but I like this approach a lot better.
[size=2]We export most C objects as lightuserdata, to minimize the load on the garbage collector. This means that our C++ classes become more like "modules" in Lua -- tables grouping functions. So, you can't actually call unit:set_position(...) in our Lua API, you have to call Unit.set_position(unit,...)
And most importantly, I want something that won't be broken each times there's an update (I use Linux/Debian Testing, so updates could happen quite frequently)Does this mean that you have no control over when updates to your dependencies occur, or which version you're compiling against? If so, that's a huge red flag and is really unprofessional -- e.g. a QA department couldn't even begin to validate your game if you can't control what code is being included in a build. You need to have full control over your dependencies. I'd sort this out before rejecting libraries based on this fault.
Author
Hello,
first of all, thanks for the reply. I will consider to have a look at it, even if it means to spend time studying lua's internals. I think this (http://lua-users.org...indingWithLunar) is a bit like what you said. Anyway, at a second thought, it seems your idea looks to be a very good solution: since it won't change often, it will remain stable and robust. Since I could add what I want, it will remain little, easy to maintain and fast.
To answer your second part: I want something that runs with C++ 03, which supports OpenGL 2.x... and that support lua 5.1 (or above). That's enough for me, and that should be enough for everyone.
If things work with luabind 0.9.0 but stop to work with luabind 0.9.1, or work with lua 5.1 but stop with lua 5.2, that simply means for me that there's something bad in these solutions, not with mine. Here (http://www.lua.org/versions.html), noone can read that something was broken between the last two releases, for example.
I know some will argue that GL 3.x and above deprecated many functions of GL 2.x and below, but this is something different. I expect minor verisons not to destroy intentionaly what was made in the just previous minor version.
For general concerns, linux distributions (at least in Debian) provide several versions of programs, ie c++ compiler with different minor versions, lua 5.1 and 5.2 ... which, normally, should help people to keep a coherent, stable and robust developping system. However this is not always easy, and when we do things alone (long time projects, in several years), it is important to consider dependency evolutions, ie, move to C++ 11, move to GL 3.X or even 4.X, use lua 5.2...
Another important point about linux distributions (at least for Debian), is that updates happen as long as the distribution is said in testing. At a point (like at this time), it began frozen, and program versions do not change that often, only to correct bugs and security issues.
To summerize this, I just want to say that it's important to follow the evolution, not to be stuck with a release, and minor versions (as I tried to say it above) are meant to correct bugs, to add minor functionalities, and to prepare to the next major release, not to destroy old functionalities.
Thanks again for your reply.
first of all, thanks for the reply. I will consider to have a look at it, even if it means to spend time studying lua's internals. I think this (http://lua-users.org...indingWithLunar) is a bit like what you said. Anyway, at a second thought, it seems your idea looks to be a very good solution: since it won't change often, it will remain stable and robust. Since I could add what I want, it will remain little, easy to maintain and fast.
To answer your second part: I want something that runs with C++ 03, which supports OpenGL 2.x... and that support lua 5.1 (or above). That's enough for me, and that should be enough for everyone.
If things work with luabind 0.9.0 but stop to work with luabind 0.9.1, or work with lua 5.1 but stop with lua 5.2, that simply means for me that there's something bad in these solutions, not with mine. Here (http://www.lua.org/versions.html), noone can read that something was broken between the last two releases, for example.
I know some will argue that GL 3.x and above deprecated many functions of GL 2.x and below, but this is something different. I expect minor verisons not to destroy intentionaly what was made in the just previous minor version.
For general concerns, linux distributions (at least in Debian) provide several versions of programs, ie c++ compiler with different minor versions, lua 5.1 and 5.2 ... which, normally, should help people to keep a coherent, stable and robust developping system. However this is not always easy, and when we do things alone (long time projects, in several years), it is important to consider dependency evolutions, ie, move to C++ 11, move to GL 3.X or even 4.X, use lua 5.2...
Another important point about linux distributions (at least for Debian), is that updates happen as long as the distribution is said in testing. At a point (like at this time), it began frozen, and program versions do not change that often, only to correct bugs and security issues.
To summerize this, I just want to say that it's important to follow the evolution, not to be stuck with a release, and minor versions (as I tried to say it above) are meant to correct bugs, to add minor functionalities, and to prepare to the next major release, not to destroy old functionalities.
Thanks again for your reply.
But I am now fed up with it for these reasons: each time there's a new version of luabind I have many problems with my development: compilation issues, linking issues and running issues (segmentation fault, not running...). For example the last time I could plainly use my program (which uses luabind) was on april. All the next releases I had broken things (out of my concern).
What I am looking for should not necessary binds the lua language. I am also opened to python. However my last attempt to use python was a disaster, mainly because of the bjam thing which I didn't succeed to make it work (if you know how to manage this, feel free to propose python).
Trouble with tools shouldn't be an important reason to choose or dismiss a scripting language. If what you are trying to do doesn't work, it can be assumed that what you are trying to do is wrong, not that tools are defective: a humble approach would be more productive. Why don't you explain your difficulties in detail in order to get help? Recommending alternative tools that you'll also make mistakes with isn't going to be very useful.
i second learning lua c api.
you will have a better understanding of how lua and c interacts. what are tables, objects etc.. actually are
you will have a better understanding of how lua and c interacts. what are tables, objects etc.. actually are
I am now looking for a good scripting language to use within C++ which will replace the current one (luabind).
Well in my opinion best two options are AngelScript ( http://www.angelcode.com/angelscript/ ) and Squirrel+Sqrat ( http://squirrel-lang.org/ + http://scrat.sourceforge.net/ )
Squirrel itself does not support C++ out of the box, but the Sqrat wrapper makes it really easy to extend c++ objects.
While Squirrel+Sqrat are easier to integrate, AngelScript is much faster and has the better support (this forum ;-) but requires you a lot of more typing.
I would agree with others that you shouldn't change your scripting language just because you are having trouble keeping up with a proper integration.
That being said, I would have 2 suggestions that would probably be different than most:
1) Embedded Mono: you can then use C# or most other .NET capable languages to extend your game as if you were using a scripting language, also giving you a wide selection of programmer/scripters to choose from.
2) Google's V8: the high-performance Javascript engine that is used in Google Chrome. Javascript is also a very widely popular language.
I've used both of these to great effect, though they are not as easy to get working as luabind, so don't expect to get up and running with either of them overnight ;)
That being said, I would have 2 suggestions that would probably be different than most:
1) Embedded Mono: you can then use C# or most other .NET capable languages to extend your game as if you were using a scripting language, also giving you a wide selection of programmer/scripters to choose from.
2) Google's V8: the high-performance Javascript engine that is used in Google Chrome. Javascript is also a very widely popular language.
I've used both of these to great effect, though they are not as easy to get working as luabind, so don't expect to get up and running with either of them overnight ;)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
