Re: ffi - C array to lua table ?

  • From: "voidptr69@xxxxxxxxxxx" <voidptr69@xxxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sun, 12 Jul 2015 01:17:08 -0400



I was just thinking... maybe there is some symmetry in the interface of service of ffi and I missed the documentation about it...
long time ago I learn that it is nice to offer that kind of symmetry of service (a way in and a way out) when you design package :o)
at least it is often what I offer :o)


On 2015-07-11 6:57 PM, demetri wrote:


This isn't time critical stuff but I'd like to know if this

normal or whether I do something wrong?


I'm hardly an expert on "normal", and I would speculate
that Lua in particular has more "weird" deployments than
most other languages -- so even the notion of "normal"
Lua/LuaJIT might not be that useful :) Having said that ...

The way I see it you're getting some additional memory
safety (by doing your work on tables instead of arrays).
And you get some (possibly a lot) more convenience from
using familiar table functions, or libraries that assume Lua
tables.

You're paying with some extra memory traffic, GC load,
and CPU cycles doing the conversions.

Depending on the size of the tables you may also care
about the increased risk of exhausting the space available
for pure Lua (vs ffi.C.malloc) data structures.

Finally, if you weren't restricting to floats (and e.g. had
int64[]) then you'd also be running the risk of range
incompatibilities converting back and forth to Lua numbers.

Whether that's a good tradeoff is entirely up to you :) But
I don't see anything wrong or inherently unusual about it.
Convenience and safety are valuable, so, if the costs listed
above are insignificant for your work, it sounds like a
perfectly reasonable choice.

Demetri

Other related posts: