Re: Re: How to export associative arrays to an embedded lua script?

[Jerome Vuarand <jerome.vuarand@...>]

2015-10-12 14:03 GMT+01:00 linuxfan@tin.it <linuxfan@tin.it>:
> Second, sorry again - I don't
> want to be pedantic, but someone could explain me better than the
> manual?
> Here: http://www.lua.org/manual/5.2/manual.html#4.5the lua manual says
> that a host application can store data in the registry, and also says
> that "you should use as key a string containing your library name, ...,
> or any Lua object created by your code". What I understand is that "lua
> objects created by your code" means "created by the host application".

It can be the host application, or binary modules loaded for example
through require. All native code has access to the registry. If your
host application lets script load binary module, you need to be aware
that your binary code is not the only code accessing the Lua state
using its C API.

> If so, this implies that it is safe to take the lua value for an object
> (say, "its pointer"), and use it in whatever manner because that value
> will never change (as long as the object exists, of course). If such a
> value is good to be used as a key in the registry, it is also good to
> be used as a key in the host application. or not?

No, you cannot use the pointer, because when accessing the registry
you need a proper Lua reference, and you cannot recreate a Lua
reference from a pointer to a table or userdata. You need to either be
able to retrieve the Lua reference, or recreate it. For example you
can use a number or a light userdata which you can easily store in
your Pascal code, and later push them on the stack to re-create a
reference. Or you can use a string, that you can copy in your Pascal
code memory (don't use the pointer from lua_tostring).

You can also use mutable objects like full userdata or tables, but
that's more complicated. You cannot store a pointer to them. To use
these as registry keys, you need to keep proper Lua references to
them, somewhere else than in the registry (otherwise you bite your
tail). You can store these references in several other places. For
example you can keep them on the stack, or you can keep them as
upvalues to your lua_CFunction-s.

Usually light userdata are recommended for this, because if you use
the address of one of your own objects, there is little chance of a
collision with a light userdata generated by another module. And light
userdata being simple values, it's easy to store them in your
application structures.