I want to get into programming with Lua and C++, and was wondering what library to go with. To my knowledge my three options are with the build in C API, Luablind, and LuaGlue. LueGlue would be more easy for me to learn since I got an old book about it (Game Development with Lua by Schuytema and Manyen) but would it be more practical to take more time and try to learn Luablind? Or go back to the basics and learn though the C API? Thanks for taking the time to read this.
I use LuaBind and I see no problems with it, the tricky part is building and setting it up.
You should at the very least [I]try[/I] vanilla Lua before you jump straight to a helper library.
Lua is very simple to wrap your head around and once you really get into how it works it can be incredibly powerful.
I've never wanted nor needed a helper library for it.
Personally I quite enjoy using the C API, but that's just me; it does make it harder to get your objects exposed to Lua than if you let Luabind do it for you.
@ArmiCasd: Any good tutorials that you know of?
Edit:
@DrMagnusson: Good idea
[QUOTE=william_g;31225731]@ArmiCasd: Any good tutorials that you know of?
[/QUOTE]
I just used the examples on their website
As others have said, the original C API is not that bad. Luabind is pretty nice, but it always made the compile times much longer for me.
LuaBind uses Boost. So no.
what do you guys think of LuaJIT?
[QUOTE=DevBug;31235739]LuaBind uses Boost. So no.[/QUOTE]
What's bad about the Boost library?
[editline]20th July 2011[/editline]
Yeah I would use the C API. Once you understand about the stack and stuff it's really easy.
Having a problem setting it all up the C API. I add the include folder in the include Directions and add the library to the library Directions. Still getting errors with the linker(I think its the linker anyways):
[code]
extern "C"
{
#include <stdio.h>
#include <string.h>
#include "lauxlib.h"
#include "lualib.h"
#include "lua.h"
}
int main(void)
{
char buff[256];
int error;
lua_State *L = lua_open();
luaL_openlibs(L);
while(fgets(buff, sizeof(buff), stdin) != NULL)
{
error = luaL_loadbuffer(L,buff,strlen(buff),"line") || lua_pcall(L,0,0,0);
if(error)
{
fprintf(stderr,"%s",lua_tostring(L,-1));
lua_pop(L,1);
}
}
lua_close(L);
return 0;
}
[/code]
[code]
1>------ Build started: Project: luaAndc++, Configuration: Debug Win32 ------
1> main.cpp
1>main.obj : error LNK2019: unresolved external symbol _lua_close referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol _lua_settop referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol _lua_tolstring referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol _lua_pcall referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol _luaL_loadbuffer referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol _luaL_openlibs referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol _luaL_newstate referenced in function _main
1>C:\Users\William\Desktop\C++\luaAndc++\Debug\luaAndc++.exe : fatal error LNK1120: 7 unresolved externals
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
[/code]
Did you include the libraries? It seemed you have just included the headers
The library is include its under library directories
Did you include the lua51.lib files and stuff in your project settings?
This is what I did:
1: Project->propertys->VC++ Directories
2: Add lua\5.1\include to the include directories
3: Add lua\5.1\library to the library directoires
You need to use the "Include Additional Dependancies" thing in the linker settings and put the lua51.lib files and stuff in. Also I remember for C++ instead of having all those .h files you can just include the lua.hpp file
Thanks for all the help
Yes. I had to hurdle through all of that by myself when I first started using external libraries. Basically for any library you use, set directories, then add the .lib files.
[editline]20th July 2011[/editline]
Unless it is a header only library that is.
[QUOTE=DevBug;31235739]LuaBind uses Boost. So no.[/QUOTE]
You'll have to go a bit further than that if you want the OP to decline using LuaBind just because it uses one of the most well built and useful library in the C++ scene that 99.9% of C++ coders should be using and abusing.
[QUOTE=gparent;31241110]You'll have to go a bit further than that if you want the OP to decline using LuaBind just because it uses one of the most well built and useful library in the C++ scene that 99.9% of C++ coders should be using and abusing.[/QUOTE]
Cross-platform readiness is a must. Oh and not to mention the memory limits on some platforms.
Oh come on, it's Boost.
How could you possibly hate Boost?
[QUOTE=Gbps;31241575]Oh come on, it's Boost.
How could you possibly hate Boost?[/QUOTE]
Because it's Boost.
[QUOTE=Richy19;31237528]what do you guys think of LuaJIT?[/QUOTE]
It's the bee's knees. Plus, if you use nothing but Lua C API, you can switch out the binaries as a stand in replacement. It's great.
[QUOTE=amcfaggot;31241857]It's the bee's knees. Plus, if you use nothing but Lua C API, you can switch out the binaries as a stand in replacement. It's great.[/QUOTE]
Don't all lua implementations/wrappers use nothing but the lua c api?
[QUOTE=Map in a box;31242855]Don't all lua implementations/wrappers use nothing but the lua c api?[/QUOTE]
Sorry, perhaps my explanation was misleading. Depending on how much you shit on Lua (custom implementations without properly extending the language) or rely on class interfaces, your ability to use other stand-in replacements/variants of Lua decrease.
[QUOTE=DevBug;31241494]Cross-platform readiness is a must. Oh and not to mention the memory limits on some platforms.[/QUOTE]
That's great, but the OP never mentioned working on some obscure platform that doesn't work with Boost.
[QUOTE=gparent;31269704]That's great, but the OP never mentioned working on some obscure platform that doesn't work with Boost.[/QUOTE]
You've also got compiler support, platform readiness is a multitude of things.
Just say you don't like Boost. Stop hiding behind your smokescreen of it not being cross platform.
[QUOTE=DevBug;31270441]You've also got compiler support, platform readiness is a multitude of things.[/QUOTE]
Still doesn't change my argument. He hasn't mentioned that being a problem. You just have an agenda against Boost, for whatever reason. It's easy to see. Boost is "more" cross-platform than many libraries out there.
Sorry, you need to Log In to post a reply to this thread.
