SWIG considers C's enum as userdata. (I checked the source it generated. Perhaps a bug?). Then, I need to create userdata inside the Lua scripts itself... Any good ways?
Then, I need to create userdata inside the Lua scripts itself.
No. You want to create one of the enumerator values within Lua. You do that pretty much as you would in C: use the enumerator's name. This is an object that has the value of the enumerator. However SWIG's Lua component decides to marshal this is irrelevant; just use the name in your Lua code.
Related
Lua's require(<name>) function, if called on a <name>.dll, will look for a function called luaopen_<name>.
What should I do if I want to say require("folder1.folder2.library")? It's not like I can name a function luaopen_folder1.folder2.library.
I am looking for a way to do this that doesn't involve changing Lua's module path—i.e. a way to do this that scales with the complexity of a project.
Name the function luaopen_folder1_folder2_library.
I want to pass a C++ object to Lua and use the same object in Lua. I have seen example of creating C++ objects in Lua and use them. But I want to do like this below.
Create a C++ object in C++ code
Pass this to Lua scripts and get some return values.
I have gone through these examples here.
http://loadcode.blogspot.sg/2007/02/wrapping-c-classes-in-lua.html
https://gist.github.com/kizzx2/1594905
But they are creating C++ objects in Lua and using them in Lua scripts.
can you please give some pointers.
Given that you did read some userdata manuals, it is very easy to achieve that. The only diference is that in regular ud manual they create objects in Lua function and you already have an object. Just push new userdata of pointer size and set it's metatable to Lua class's metatable (which you prepared anyway).
void **ud;
ud = lua_newuserdata(L, sizeof(*ud));
*ud = object; // existing
luaL_getmetatable(L, tname);
lua_setmetatable(L, -2);
// ud at top of stack
lua_setglobal(L, "foo");
Where tname is your Lua-side classes metatable name.
As you don't want to use the objects within Lua (just pass them on to C++), you can wrap them as a lightuserdata (see here) from C++, and later just pop it (you may want to check if it is_lightuserdata before).
I think I saw somewhere a native function in Lua that can return a new userdata. Does it exist? Is it possible to create custom userdata from normal Lua script?
You may be thinking of newproxy
From: http://lua-users.org/wiki/HiddenFeatures
newproxy is an unsupported and undocumented function in the Lua base
library. From Lua code, the setmetatable function may only be used
on objects of table type. The newproxy function circumvents that
limitation by creating a zero-size userdata and setting either a new,
empty metatable on it or using the metatable of another newproxy
instance. We are then free to modify the metatable from Lua. This is
the only way to create a proxy object from Lua which honors certain
metamethods, such as __len.
It was also useful for __gc metamethods, as a hack to get a callback when the newproxy instance becomes free.
This feature was present in Lua 5.1, but removed in 5.2. In Lua 5.2, __gc metamethods can be set on zero sized tables, so the main impetus for newproxy went away.
Actually no, in pure Lua.
The type userdata is provided to allow arbitrary C data to be stored in Lua variables. … Userdata values cannot be created or modified in Lua, only through the C API. This guarantees the integrity of data owned by the host program.
link
If you embed luaVM in host C/C++ application, you can export some function to create userdata to Lua, but it's not a good practice. UD is designed to be a blackbox for Lua scripts.
Can someone give me any suggestions as to how to use this function from Lua:
HH_DISPLAY_TOPIC (MSDN)
I'm just a bit confused as to how to call the function as in is it from a dll or do I need to make a dll or is this a Luacom type of scenario.
Lua cannot go out into random DLLs and start calling random C functions1. If you want to call some code in a DLL, then you need to write a proper Lua module in C that will load this DLL and marshall the call from Lua to the DLL. Lua can read regular Lua modules and act accordingly.
1: If you're using LuaJIT, you can do this via their FFI stuff. To a degree, as you'll need to provide a string describing the interface for the functions you want to call.
When making Lua bindings for C++ classes, should I return tables or userdata objects?
Does anyone know any of the pros and cons for each method?
I recommend returning userdata. Regardless of approach, there has to be somewhere to put the pointer
to the C++ data, or the actual C++ data itself, and there's nowhere
safe to do this with a table.
Returning tables would make sense in some situations, because they can
be 'annotated' in Lua with extra attributes without one's having to do
anything extra to support this. Unfortunately the C++ object pointer
has to go somewhere, and there's nowhere sensible for it to go other
than an actual entry in the table itself.
This is not a very safe place for it to go. It can be found by Lua
code, and removed or replaced. This could be by accident, or on
purpose, it doesn't really matter.
My preference therefore is to return userdata objects. They can be
made to work like tables if one really must insist upon that, but they
also have a "secret" area (the actual userdata itself) where the C++
object pointer can be stored, safe from overwriting by Lua code.
(Userdata objects also have an "environment" pointer, which is another
place to store object-specific data. As with the userdata payload
itself, this value is inaccessible to Lua code and can't be damaged
that way.)