Re: Problem passing more than one argument to a Lua function that's inside a table from C++.

["Anner J. Bonilla" <annerjb@...>]

Yeah i joined the lua irc channel and shairik pointed that out to me.
operator precedence was wrong so it always evaluated to the opposite
of what i expected. Still Thank's for replying

On Mon, May 11, 2009 at 9:48 PM, Duncan Cross <duncan.cross@gmail.com> wrote:
> On Tue, May 12, 2009 at 12:47 AM, Anner J. Bonilla <annerjb@gmail.com> wrote:
>> I been trying to get this small application to run since it's a
>> testbed for future functionality on my game engine. But i am having
>> some trouble trying to get it to call a function inside a lua table
>> from C++. More precisely is passing more than one parameter to the lua
>> function, return values work fine. also calling a function that's not
>> member of a table works flawlessly without any of the argument
>> trouble.
>>
>>
>> This is my code without comments and debugging functions.
>> inside my main function in c++ i call 4 functions each one returning 1
>> if they execute correctly or 0 otherwise.
>>
>> their name reflects the amount of parameter than they take and test for.
>> i have spended about 5 hours today with this trying different
>> approaches. so any ideas or suggestions would be greatly appreciated
>> my suspicions are that something i am doing with the stack
>> manipulation section is wrong. but doubt it because it works fine with
>> less than 2 arguments and because when i dump the stack the values
>> appear to be what they should be. ie
>>
>> table
>> function
>> argument
>> argument
>>
>> after doing the pcall the only thing left on the stack is:
>> table
>> number
>> the number being the return value and i assume the table is the one
>> the function was member of.
>>
>> //main.cpp
>> http://pastebin.com/m2f1787b
>> //add.lua
>> http://pastebin.com/m59b0ead9
>>
>> Anner
>>
>
> Hi Anner,
>
> In add.lua, the test functions use the expression 'not x == nil' to
> test that function parameter x is being passed - but in Lua, the "not"
> operator binds tighter than "==" (see section 2.5.6 in the manual for
> an explicit order of precedence). This means that it gets evaluated as
> '((not x) == nil)' rather than '(not (x == nil))', which will always
> evaulate to false.
>
> -Duncan
>