[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: typed arrays
- From: Coda Highland <chighland@...>
- Date: Thu, 27 Sep 2012 20:34:30 -0700
http://luajit.org/ext_ffi_api.html
https://github.com/jmckaskill/luaffi/blob/master/README.md
On the Lua side, once it's been declared, it acts just like a table,
with API functions for additional manipulation. On the C side, it's
just a pointer of the desired type, which can be handled however you
want.
/s/ Adam
On Thu, Sep 27, 2012 at 8:28 PM, Tom <tmbdev@gmail.com> wrote:
> I'm not sure which LuaJIT API you are referring to; do you have a URL? Does
> that API require any support from LuaJIT?
>
> Tom
>
> On Thu, Sep 27, 2012 at 8:13 PM, Coda Highland <chighland@gmail.com> wrote:
>>
>> On Thu, Sep 27, 2012 at 7:53 PM, Tom <tmbdev@gmail.com> wrote:
>> > A simple API might have four functions (using Lua syntax to describe
>> > both
>> > Lua and C APIs):
>> >
>> > a = typed_vector(size,tcode) -- allocs 1D array of the given size and
>> > type
>> > a:size() -- returns the size of the 1D typed array
>> > a:type_code() -- returns the type of the 1D typed array
>> >
>> > a[index] -- needed only in Lua, for simple element access
>> > a:address_of() -- needed only in C, pointer access to elements
>> >
>> > Type codes would exist for common standard C types ("char", "uint",
>> > "float",
>> > ...), and common sized types ("uint8", "float32", "float64"), ...).
>> >
>> > Although such a simple API may mean that getting two libraries to talk
>> > to
>> > each other may involve extra copying, even with that, it's a lot faster
>> > and
>> > easier than having nothing at all. A more complex interface would be a
>> > Lua
>> > adaptation of a subset of the Python buffer and memory view APIs
>> > (http://docs.python.org/c-api/buffer.html); they allow data to be
>> > exposed
>> > without copying, but at the cost of higher complexity.
>> >
>> > Tom
>>
>> It seems to me that the best API would be the one that's native to
>> LuaJIT, as that would provide the best performance there and work with
>> no further adaptation. Imitating that (e.g. luaffi) would allow
>> non-LuaJIT projects to use the same API.
>>
>> /s/ Adam
>>
>