On Sun, Apr 7, 2019 at 1:05 PM Marc Balmer < marc@msys.ch> wrote:
> Are both variants valid?
Userdata is the only option here, because Lua strings are immutable, and this should not be violated by clever C code.
I somewhat agree. But the string copy is only used within my C function, so it does not really matter if it is modified, since Lua code never sees or uses this string. Therefore my question if this has any "technical" side/bad effects.
Frankly, the whole approach, which would then involve creating more Lua strings and calling luaL_checkoption on them, seems heavy-footed to me.
I am not pushing the strings and using luaL_checkoption, but rather a checkoption function that takes the name as const char * argument instead of getting it from the Lua stack.
If you need this to pass optional flags, I would instead consider passing them as multiple arguments, so that the Lua code could do this:
dlopen('whatever') -- no flags dlopen('whatever ', 'lazy') dlopen('whatever ', 'lazy', 'global')
This leaves the entire question of parsing to Lua's parser, the user does not have to learn your syntax, and all you need to do is something like this:
int flags = 0, top = lua_gettop(L); for (int i = 2; i <= top; ++i) flags |= (1 << luaL_checkoption(L, i, 0, list));
I did this before, but then I came accross a situation where additional parameters are specified after the flags:
func('abc', 'def', 'ghi, 'bar')
(def and ghi are or-able flags)
This would then beome
func('abc', 'def, ghi', 'bar')
of course, are third variant seems possible, using tables:
func('abc', { 'def', 'ghi' }, 'bar'}
I am looking for the way that is the most user friendly.
|
