Re: [ANN] Luaxx 0.3

[Matthew Nicholson <matt@...>]

Thomas Harning wrote:
> On May 1, 2008, at 1:19 AM, Matthew Nicholson wrote:
> > Luaxx is a thin wrapper around the Lua C API.  The wrapper adds some
> > convenience functions and integrates well with modern C++.  It is 
> > basically my conceptual port of lua to c++.  It does not yet wrap the 
> > full lua API, but it's a good start.  Please check it out and give me 
> > feedback.
> Looks pretty good so far... as for the exception throwing, you might 
> want to offer a method that will avoid the throw since the user may know 
> how to handle the error immediately without invoking the overhead of 
> exception handling.

You can use state::as and state::is to avoid exceptions, although the 
state::to functions always throw exceptions (state::as uses lua_is..() 
and lua_to..() internally).

When coding, there are some cases when you will expect a certain type 
and if lua_to...() fails you have to check for that.  For simple cases, 
you end up writing a lot of extra error checking code vs using 
exceptions.  There are also other cases where you expect any number of 
types, so you end up checking the type anyway.

Personally I prefer not to have to check if my call to lua_to... was 
successful, that way I can do things like this (and if there was a 
problem, and exception is thrown).

L.to(int_var, -1).to(str_var, -2).to(double_var, -3);

I would imagine calls to lua_to..() failing are not going to be frequent 
in speed critical code, but this is not necessarily a valid assumption 
to make.

I think offering state::to and state::as takes care of the exception 
problem in that case.

The state::pcall(), state::loadfile(), state::load(), and 
state::loadstring() always throw exceptions.  I am not sure speed 
concerns weigh over the convenience over exceptions here.  Do people 
normally call those functions in speed critical sections of code?  And 
in the event of an error, will speed still matter?  I have not used lua 
in speed critical environments, so I don't have good answers to those 
questions.

If necessary, more state::load..() and another state::pcall() function 
could be added that does not throw an exception.

Also, it just hit me.  If you don't like exceptions, this code will work 
just fine too:

lua::state L;
lua_pushcfunction(L, func);
lua_pcall(L, 0, 0, 0);

You can use the lua::state directly with the C lua API and it will 
automatically be converted into a raw pointer for use. 100% exception free.

> Also.. assuming errors are string objects is probably not the best 
> plan-of-action.  It's quite possible for other objects are thrown as the 
> error.


Yeah, i thought about that.  I figure most things are convertible to a 
string, but it is wrong to assume it is a string.  For LUA_ERRSYNTAX, 
LUA_ERRMEM, LUA_ERRRUN, and LUA_ERRFILE I think it will always be a 
string though.  I'll think about the best way to handle that.

> One of these days I'll give the API a try and see if there's any gotchas
> that I didn't see while glancing.

Thanks for the feedback.

--
Matthew Nicholson
matt-land.com