Re: Is there an easier way to deal with "inout" parameters
- From: Jay Carlson <nop@xxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 19 Aug 2012 18:24:54 -0400
On Aug 19, 2012, at 11:49 AM, William Adams wrote:
> createstring(buff, len);
>
> Question: Is there an easier way to conquer this pattern without the error
> prone nature of accessing 'needed[0]'?
>
> Ideally I'd have an 'inout' classifier I could stick onto the parameter. The
> FFI is already doing magic to marshal data types, so this would be another
> bit of magic. If I had this, then in Lua I could write:
>
> local len
> getvalue(nil, len);
> buff = ffi.new("uint8_t[?]", len);
> getvalue(buff, len);
> ffi.string(buff, len);
This is something a PUC-Rio Lua implementation of ffi would not be able to do.
Adding inout for ffi alone seems odd. For consistency, straight Lua functions
should have this ability too. Saaaay, what happens when you put something which
isn't a local lvalue in an inout slot?
Multiple return values, as in
buff, len = getvalue(nil, len)
would not be as nifty, but preserves immutability of parameters, and has
well-defined semantics.
Other related posts:
