module(L)
[
class_<CompCompiler>("CompCompiler")
.def(constructor<>())
];
module(L)
[
class_<CompCompiler>("CompCompiler")
.def(constructor<>())
.def("setSomeData", &CompCompiler::setSomeData)
];
#HEADER#
lua_State **states;
#IMPLIMENTATION#
LuaInstances::LuaInstances()
{
states = new lua_State*[10]; // increase this to add more states
states[construction] = lua_open();
states[keyboard] = lua_open();
.....
CompCompiler *example;
example = new CompCompiler();
void CompCompiler::setupLuaBinds(lua_State *L)
{
luaL_openlibs(L);
luabind::open(L);
luabind::module(L)
[
luabind::class_<CompCompiler>("CompCompiler")
.def(luabind::constructor<>())
.def("setSomeData",&CompCompiler::setSomeData)
.def("setMoreData", &CompCompiler::setMoreData)
.def("getSomeData", &CompCompiler::getSomeData)
.def("getMoreData", &CompCompiler::getMoreData)
];
lua_close(L);
}
luabind::open(L);
luabind::globals(L)["CompCompiler"] = example;
lua_close(L);
I have multiple lua_States... This is because I don't want those who write scripts to be able to call functions that were not designed for execution during what they are doing, for example, I don't want the constructor calling keybinding configuration variables...
[...]
when I call luabind::open(L); it causes an Unhandled exception.. if I remove the lua_close(L); at the end of void CompCompiler::setupLuaBinds(lua_State *L), and remove the subsequent luabind::open(L); it goes through without a hitch...
but I need to be able to close and open luabind states so I can keep the tools in which users use in a lua restricted...
[/quote]
But I thought this was the point of using different Lua states? What has closing and re-opening states got to do with segregation of functionality?
do you have ANY idea how I can setup a system which has multiple lua states so that I am able to restrict access to globals and functions when executing a lua file or a lua string?
[/quote]
Keep them open.
Your problem is with your understanding of Lua and nothing at all to do with Luabind, it seems. I think the problem is 50% attitude and 50% inexperience. Complaining about the quality of things you're misusing or haven't taken the time to understand isn't going to help your case.
So, take a deep breath, do things one step at a time (don't just pretend to do so to get more help). Understand each step before proceeding to the next. Run the code each time and check it works. Look at all the Lua/Luabind functionality you're using and understand what it does before proceeding. Luabind is an advanced library. It's going to eat people that don't yet have much C++ experience under their belts if they're not methodical about how they use it.
To this end, I recommend you step sideways temporarily and try to do something smaller before coming back to your main project. For example, create a program with 2 Lua states. Bind one C(++) function in to each state (a different function in each) and check neither Lua state can see the function bound in to the other by running some snippets of Lua code that call those functions.
When you're happy that you've got that working, return to the main project and incrementally build it up.
May I also recommend an std::vector<lua_State *> to hold your states.
attitude and 80% stress because the assignment (game engine) is due in a week...
I havn't been putting it off.. it's just a stupidly massive assignment, I've been working on for 2 months
lua_close()...
[font=helvetica, arial, verdana, tahoma, sans-serif][color=#282828]
you gotta understand I am stressing a lil atm
