After some painstaking research from a long discussion of comments, I am posting this answer to help summarize the situation and hopefully offer some useful tips.
The main problem OP was facing was that the wrong print function was called in the lua script test. Unlike the source code, the actual code that the OP tested was calling Print(myVar) , which is a custom lua_CFunction function, not a built-in print function.
Somehow along the way, this led to the creation of some instance of template <typename RT> class LuaFunction and the call to the overloaded operator()() . From the luafunction.h check from luaPlus, any lua errors that occur inside this call will be swallowed without any logging (not a very good design solution for the luaPlus part):
if (lua_pcall(L, 0, 1, 0)) { const char* errorString = lua_tostring(L, -1); (void)errorString; luaplus_assert(0); }
To help catch future errors like this, I suggest adding a new luaplus_assertlog macro. In particular, this macro will include errorString so that the context is not completely lost and hopefully helps with debugging. This change, hopefully, will not violate existing uses of luaplua_assert from other parts of the API. Ultimately, it is probably best to modify luaplus_assert so that it really includes something meaningful.
In any case, there have been changes:
LuaPlusInternal.h
@@ -81,5 +81,6 @@ } // namespace LuaPlus #if !LUAPLUS_EXCEPTIONS +#include <stdio.h> #include <assert.h> #define luaplus_assert(e) if (!(e)) assert(0) @@ -84,5 +85,6 @@ #include <assert.h> #define luaplus_assert(e) if (!(e)) assert(0) +#define luaplus_assertlog(e, msg) if (!(e)) { fprintf(stderr, msg); assert(0); } //(void)0 #define luaplus_throw(e) assert(0) //(void)0
LuaFunction.h
@@ -21,7 +21,7 @@ class LuaFunction { public: - LuaFunction(LuaObject& _functionObj) + LuaFunction(const LuaObject& _functionObj) : functionObj(_functionObj) { } @@ -36,7 +36,7 @@ if (lua_pcall(L, 0, 1, 0)) { const char* errorString = lua_tostring(L, -1); (void)errorString; - luaplus_assert(0); + luaplus_assertlog(0, errorString); } return LPCD::Type<RT>::Get(L, -1); }
In the change above, I decided not to use std::cerr simply because C ++ streams tend to be heavier than simple C-style idio functions. This is especially true if you use mingw as a toolchain - the ld linker cannot remove unused C ++ stream characters, even if your program never uses it.
With this in place, here is an example where an unprotected call is made using the lua function so that you can see the errorString printout before failure:
// snip... int main(int argc, const char *argv[]) { LuaStateAuto L ( LuaState::Create(true) ); LuaObject globals = L->GetGlobals(); globals.Register("Test", Test); globals.Register("Print", Print); if(argc > 1) { /* if (L->DoFile(argv[argc - 1])) std::cout << L->CheckString(1) << '\n'; /*/ L->LoadFile( argv[argc - 1] ); LuaFunction<int> f ( LuaObject (L, -1) ); f(); //*/ } }
Doing the above will crash, but will include a semi-official error message:
g++ -Wall -pedantic -O0 -g -I ./Src -I ./Src/LuaPlus/lua51-luaplus/src plustest.cpp -o plustest.exe lua51-luaplus.dll plustest.exe plustest.lua plustest.lua:2: bad argument