Re: LuaJIT 2 ffi (casting / force hotpath)

[Mike Pall <mikelu-1101@...>]

CrazyButcher wrote:
> looking at the source I also noticed that all individual enums become global
> 
> ffi.cdef "enum Type {TA,TB,TC};"
> will mean there is
> ffi.C.TA (returning 0)
> ffi.C.TB (returning 1) and so on

You can create scoped enums (actually a C++ feature). They are
still global in C mode (they have to), but would be local in a
future C++ mode. Scoped static const values are indeed local:

  ffi.cdef[[
  struct foo {
    enum { NO, YES, MAYBE };
    static const int MAGIC = 42;
    int a, b;  // Or whatever members this struct needs.
  };
  ]]

  local s = ffi.new("struct foo")
  print(s.YES)       --> 1
  print(s.MAGIC)     --> 42

  print(ffi.C.YES)   --> 1
  print(ffi.C.MAGIC) --> error, MAGIC is not a global symbol

  s.a = s.MAYBE
  if s.b == s.YES then ... end

> this is certainly C style as it just becomes an int. But for
> type-safety it would be kind of cool if one cannot pass a number to a
> function "someFunc(Type)" but has to use the real enum. Although, well
> there is also cases where I hate c++ for not taking an int ;)

Well, I don't want to copy _all_ of the joys of C++ in Lua. :-)
So LuaJIT simply allows all of these:

  ffi.cdef[[
  typedef enum { RED, GREEN, BLUE } PrimaryColor;
  int bar(PrimaryColor x);
  ]]

  ffi.C.bar(2)
  ffi.C.bar(ffi.C.BLUE)
  ffi.C.bar("BLUE") -- Strings are (type-safe!) converted to enums.

> I also was able to create an cdata object of "Type", but I guess the
> main use case for that is if a pointer to Type was required as
> function argument? Otherwise using numbers would be fine or? I didn't
> try with a enum function argument yet, but I'd expect it to not take
> an int*, but insist on Type*

Scalar cdata objects are treated like their contents, but are only
useful in certain circumstances (e.g varargs). The type conversion
rules are the same as for C, with small changes to allow better
interoperability with Lua types. So enums are treated like their
base type and are fully interchangeable with integers. The rules
for pointer compatibility are mostly the same as for C, too.

> in a c++ mode one could think of using
> ffi.CPP.Type.TA

Not sure about the namespace issues, yet. But see above: you can
use an instance of a type right now.

BTW: Another C++ feature the FFI already supports are references
     ('int &x'), which are quite useful for struct fields.

> design wise a ffi.CPP and ffi.cppdef with namespaces and such would
> probably be the cleaner way to go about and rather keep the C mode
> like C works.

Dang! You discovered my secret plan ...

> Regarding the callbacks, the only way to get this for now is having a
> regular C function, which then calls the lua runtime to push
> arguments, and retrieves returns afterwards?

Yes, that would work (more or less) as an interim solution.

> But how would I be able to convert the cdata args and returns of a
> function safely to what the C function must deal with.
> 
> For that to work, you would need to expose your cdata conversion
> handling via LuaJIT's C Api somehow or?

Well, you'd need to convert to plain Lua objects then. There's no
support for creating/accessing cdata objects in the old Lua/C API.
This will not be needed once I implement automatic callback
generation.

> probably has been answered before but luajit2 is thread-safe, or? A
> brief look at luaL_newstate shows per LuaState thread-safe allocators.

Yes. But due to the separate allocators you should try to pool or
recycle states (they are not bound to any specific thread).

--Mike