Re: C++ binding: arg errors

[Nick Gammon <nick@...>]

On 06/10/2006, at 9:23 AM, Glenn Maynard wrote:

> That's exactly what I'm doing: the type is pulled out of the first  
> argument
> (for passing to the actual C++ method) and removed from the stack, but
> that's what causing the problem.
>
> luaL_argerror() assumes that if a function is a method call (according
> to lua_getinfo), then the first argument is "self", and reports
> accordingly.  I've removed that argument, and it doesn't know that,
> so when I say "foo:PrintString(nil)", I get errors like "calling  
> PrintString
> on bad self (got nil, expected string)", instead of "bad argument #1".

This is bad news.

Now I see my application has the same problem. ;)

I had assumed that these were equivalent:

foo:bar (x)

and

bar (foo, x)

However you are right, they report errors differently. Pulling "foo"  
off the stack does indeed result in strange error messages, but not  
pulling it means that when I want argument 1, I have to really ask  
for argument 2. Somehow this seems strange to me, that if I ask for  
argument 2, and it is in error, it reports argument 1 as being wrong.

In my case, the argument was optional. Without going into a lot of  
boring detail, there was a default thing (game world in my case),  
which if you wanted the default, you didn't need to specify it.  
However if you wanted to operate over a different one (eg. world A  
applies a command to world B) then you need to specify, eg.

B:SendMessage ("boo")

or, what I thought was equivalent:

SendMessage (B, "boo")

This has opened up an unfortunate can of worms, which neither I, nor  
my users, realized existed until I read this post.

All I can suggest now is to leave the self on the stack, and instead  
change things like luaL_checkstring (and so on) to use a stub  
function that adds 1 to the requested argument.

eg.

#define my_checkstring(L,n) luaL_checkstring(L,(n)+1)

Plus, in my case, rather than removing the optional self, I will have  
to push one on, if it wasn't there before.


Unless there is a way of convincing Lua that once the "self"  
parameter has been removed (with lua_remove) that it is not in fact  
there any more.

- Nick