Here is my C++ main function :
int main() {
lua_State* L = luaL_newstate();
luaL_openlibs(L);
getGlobalNamespace(L).
beginNamespace("o").
beginClass<Object>("Object").
addConstructor<void (*) (double, double)>().
addProperty("width", &Object::getWidth, &Object::setWidth).
addProperty("height", &Object::getHeight, &Object::setHeight).
addProperty("x", &Object::getX, &Object::setX).
addProperty("y", &Object::getY, &Object::setY).
endClass().
endNamespace();
lua_pcall(L, 0, 0, 0);
luaL_dofile(L, "main.lua");}
And here is my main.lua for Love2D
function love.load()
obj = o.Object(10, 20) end
When i tried to run it with love it says that obj is a nil value and i realized that Love2D doesn't run my main function in C++ to create the object class.
How do i call a C++ main function in Lua using LuaBridge?
What you are doing is using two separate programs: the one you build with your "main function", and the actual Love2D executable. They're separate executables; they have no more relation to one another than lua.exe has to python.exe.
What you appear to be wanting to do is write a C++ library that is used by Love2D. You can do that, but it requires that you write, not a C++ program, but a dynamic library. You have to write a Lua C-module.
How you write a dynamic library depends on your platform of choice. But that dynamic library must export the appropriate functions, as detailed in the Lua 5.1 documentation. If your C module is named "test", then it must export a function called luaopen_test.
The job of this function is essentially what your main does. Your luaopen_ function does not have to create a Lua state; it will be given one. It's job is to return a table that contains the functions and APIs you want to export in your module. So it registers everything with Lua as needed.
Your main puts its stuff in the global "namespace", but this is generally considered quite rude. It's better to build a local table and put your stuff there, returning the table as the return value. I'm not familiar with LuaBridge's API, so I have no idea how to go about doing that.
Worst case is that you could build a global table as you currently do, but after building it, load it into a local table, clear the global entry, then return the table.
Related
I have a working set of TCL script plus C++ extension but I dont know exactly how it works and how was it compiled. I am using gcc and linux Arch.
It works as follows: when we execute the test.tcl script it will pass some values to an object of a class defined into the C++ extension. Using these values the extension using a macro give some result and print some graphics.
In the test.tcl scrip I have:
#!object
use_namespace myClass
proc simulate {} {
uplevel #0 {
set running 1
for {} {$running} { } {
moveBugs
draw .world.canvas
.statusbar configure -text "t:[tstep]"
}
}
}
set toroidal 1
set nx 100
set ny 100
set mv_dist 4
setup $nx $ny $mv_dist $toroidal
addBugs 100
# size of a grid cell in pixels
set scale 5
myClass.scale 5
The object.cc looks like:
#include //some includes here
MyClass myClass;
make_model(myClass); // --> this is a macro!
The Macro "make_model(myClass)" expands as follows:
namespace myClass_ns { DEFINE_MYLIB_LIBRARY; int TCL_obj_myClass
(mylib::TCL_obj_init(myClass),TCL_obj(mylib::null_TCL_obj,
(std::string)"myClass",myClass),1); };
The Class definition is:
class MyClass:
{
public:
int tstep; //timestep - updated each time moveBugs is called
int scale; //no. pixels used to represent bugs
void setup(TCL_args args) {
int nx=args, ny=args, moveDistance=args;
bool toroidal=args;
Space::setup(nx,ny,moveDistance,toroidal);
}
The whole thing creates a cell-grid with some dots (bugs) moving from one cell to another.
My questions are:
How do the class methods and variables get the script values?
How is possible to have c++ code and compile it without a main function?
What is that macro doing there in the extension and how it works??
Thanks
Whenever a command in Tcl is run, it calls a function that implements that command. That function is written in a language like C or C++, and it is passed in the arguments (either as strings or Tcl_Obj* values). A full extension will also include a function to do the library initialisation; the function (which is external, has C linkage, and which has a name like Foo_Init if your library is foo.dll) does basic setting up tasks like registering the implementation functions as commands, and it's explicit because it takes a reference to the interpreter context that is being initialised.
The implementation functions can do pretty much anything they want, but to return a result they use one of the functions Tcl_SetResult, Tcl_SetObjResult, etc. and they have to return an int containing the relevant exception code. The usual useful ones are TCL_OK (for no exception) and TCL_ERROR (for stuff's gone wrong). This is a C API, so C++ exceptions aren't allowed.
It's possible to use C++ instance methods as command implementations, provided there's a binding function in between. In particular, the function has to get the instance pointer by casting a ClientData value (an alias for void* in reality, remember this is mostly a C API) and then invoking the method on that. It's a small amount of code.
Compiling things is just building a DLL that links against the right library (or libraries, as required). While extensions are usually recommended to link against the stub library, it's not necessary when you're just developing and testing on one machine. But if you're linking against the Tcl DLL, you'd better make sure that the code gets loaded into a tclsh that uses that DLL. Stub libraries get rid of that tight binding, providing pretty strong ABI stability, but are little more work to set up; you need to define the right C macro to turn them on and you need to do an extra API call in your initialisation function.
I assume you already know how to compile and link C++ code. I won't tell you how to do it, but there's bound to be other questions here on Stack Overflow if you need assistance.
Using the code? For an extension, it's basically just:
# Dynamically load the DLL and call the init function
load /path/to/your.dll
# Commands are all present, so use them
NewCommand 3
There are some extra steps later on to turn a DLL into a proper Tcl package, abstracting code that uses the DLL away from the fact that it is exactly that DLL and so on, but they're not something to worry about until you've got things working a lot more.
I have a C++ program that creates a lua_State and run custom Lua script. If I would like to have the lua_State pre-load cjson instead of requiring calling "require" in the Lua code, can I know whether it is possible and how can I do that?
Yes, it's possible. Use luaL_requiref for that. Use this or this function as argument. You'll need to link the cjson code to your executable, and the compiler would probably appreciate a function declaration for the luaopen_* functions. If you use Lua 5.1 (which doesn't have luaL_requiref yet) you can use or steal from Compat-5.3.
You could call require once through C++ and make a global variable out of the return value if you don't want to call require in scripts.
For example in C++ do:
if (luaL_dostring(L, "cjson = require(\"cjson\")")) // run code
std::cout << luaL_checkstring (L, -1) << std::endl; // print error
and after that you can use cjson in your scripts like cjson.new() without any require or such calls as it exists as a global variable.
Since require was used by C++ then calling require in lua later on will not run the cjson file again unlike using dofile or similar
I've got damn big problem. As you know Lua allows making modules and you can load these modules with require() function from 5.1(previously loadlib).
#define LUA extern "C" __declspec(dllexport) int __cdecl
static int l_TestFunc(lua_State * L)
{
lua_pushboolean (L, 1); // return true
return 1;
}
LUA luaopen_MyModule(lua_State *L)
{
printf("test2");
lua_pushcfunction(L, l_TestFunc);
lua_setglobal(L, "TestFunc");
return 1;
}
so in Lua you are just using require("MyModule") and everything works.(luaopen_* is entry point then)
But I need to use standard way(DllMain as entry point). I tried but it didn't work.
Got any ideas?
But I need to use standard way(DllMain as entry point). I tried but it didn't work. Got any ideas?
DllMain is always going to be your entry point (if defined), but you can't use it to load your functions because you have no Lua state to load them into there.
When you run "require" in Lua code, the app executing that code (e.g. lua.exe) will load your DLL (invoking DllMain), then call luaopen_MyModule passing in the Lua state that executed the require statement. There's no way for your DllMain to have access to that state pointer...
...well, no ordinary way. You could work something out so that the host apps writes the memory location of the Lua state to some external location accessible to your DLL (registry, file, etc.) before loading your DLL. Your DLLMain could fetch the pointer register and it's functions into that state. Not sure why you'd want to do that, but in a language like C it's technically possible.
This would require that you wrote the host, so you could arrange to write the state somewhere. Or you could have a separate module, loaded the ordinary way, which writes the Lua_state value, then all other modules could access it from their DllMains.
This smells a lot like an XY Problem. Care to share why you want to register your functions in DllMain?
Try this...
Instead of using the name MyModule in require("MyModule") and luaopen_MyModule use the name of the executable that your DLL is injected into. If that doesn't work change the require call to have .exe at the end.
Lua's require is going to call Win32 LoadLibrary and then GetProcAddress to find the luaopen function. Both calls will use the argument to require(). It appears that PE-inject makes all the functions in the injected DLL appear as if they are in the EXE module. So, you need LoadLibrary to return the handle to the EXE module and then GetProcAddress will find the injected luaopen function.
The are a few reasons this might not work. One is that Lua's require does have the requirement that the DLL file name and the DLL module name match. That's not a Win32 requirement and so might not be the case for your portable executable.
In my interpreter I have built-in functions available in the language like print exit input, etc.
These functions can obviously be accessed from inside the language. The interpreter then looks for the corresponding function with the right name in a vector and calls it via a pointer stored with its name.
So I gather all these functions in files like io.cpp, string.cpp, arithmetic.cpp. But I have to add every function to the function list in the interpreter in order for it to be found.
So in these function files I have things like:
void print( arg )
{
cout << arg.ToString;
}
I'd add this print function to the interpreter function list with:
interpreter.AddFunc( "print", print );
But where should I call the interpreter.AddFunc?
I can't just put it there below the print function as it has to be in a function according to the C++ syntax.
Where and how should all the functions be added to the list?
In each module (io, string, etc.), define a method that registers the module with the interpreter, e.g.:
void IOModule::Register(Interpreter &interpreter) {
interpreter.AddFunc( "print", print );
//...
}
This can also be a normal function if your module is not implemented in a class.
Then in your application's main initialization, call the register method of all modules.
This approach helps keep things modular: The main application initialization needs to know which modules exist, but the details of which functions are exported are left to the module itself.
The simplest is to keep a map of function names to function pointers and load that at program startup. You already have the functions linked into the interpreter executable, so they are accessible at the time main() is called.
You can also come up with a scheme where functions are defiled in the dynamic libraries (.dll or .so depending on the platform) and some configuration file maps function names to libraries/entry points.
Is everything included in every interpreter? If so, I would recommend adding it either in a constructor (assuming the interpreter is an object) or an init method.
If not, you may want to consider adding an "include" type directive in your language. Then you do it when you encounter the include directive.
Sooooo I'm writing a script interpreter. And basically, I want some classes and functions stored in a DLL, but I want the DLL to look for functions within the programs that are linking to it, like,
program dll
----------------------------------------------------
send code to dll-----> parse code
|
v
code contains a function,
that isn't contained in the DLL
|
list of functions in <------/
program
|
v
corresponding function,
user-defined in the
program--process the
passed argument here
|
\--------------> return value sent back
to the parsing function
I was wondering basically, how do I compile a DLL with gcc? Well, I'm using a windows port of gcc. Once I compile a .dll containing my classes and functions, how do I link to it with my program? How do I use the classes and functions in the DLL? Can the DLL call functions from the program linking to it? If I make a class { ... } object; in the DLL, then when the DLL is loaded by the program, will object be available to the program? Thanks in advance, I really need to know how to work with DLLs in C++ before I can continue with this project.
"Can you add more detail as to why you want the DLL to call functions in the main program?"
I thought the diagram sort of explained it... the program using the DLL passes a piece of code to the DLL, which parses the code, and if function calls are found in said code then corresponding functions within the DLL are called... for example, if I passed "a = sqrt(100)" then the DLL parser function would find the function call to sqrt(), and within the DLL would be a corresponding sqrt() function which would calculate the square root of the argument passed to it, and then it would take the return value from that function and put it into variable a... just like any other program, but if a corresponding handler for the sqrt() function isn't found within the DLL (there would be a list of natively supported functions) then it would call a similar function which would reside within the program using the DLL to see if there are any user-defined functions by that name.
So, say you loaded the DLL into the program giving your program the ability to interpret scripts of this particular language, the program could call the DLLs to process single lines of code or hand it filenames of scripts to process... but if you want to add a command into the script which suits the purpose of your program, you could say set a boolean value in the DLL telling it that you are adding functions to its language and then create a function in your code which would list the functions you are adding (the DLL would call it with the name of the function it wants, if that function is a user-defined one contained within your code, the function would call the corresponding function with the argument passed to it by the DLL, the return the return value of the user-defined function back to the DLL, and if it didn't exist, it would return an error code or NULL or something). I'm starting to see that I'll have to find another way around this to make the function calls go one way only
This link explains how to do it in a basic way.
In a big picture view, when you make a dll, you are making a library which is loaded at runtime. It contains a number of symbols which are exported. These symbols are typically references to methods or functions, plus compiler/linker goo.
When you normally build a static library, there is a minimum of goo and the linker pulls in the code it needs and repackages it for you in your executable.
In a dll, you actually get two end products (three really- just wait): a dll and a stub library. The stub is a static library that looks exactly like your regular static library, except that instead of executing your code, each stub is typically a jump instruction to a common routine. The common routine loads your dll, gets the address of the routine that you want to call, then patches up the original jump instruction to go there so when you call it again, you end up in your dll.
The third end product is usually a header file that tells you all about the data types in your library.
So your steps are: create your headers and code, build a dll, build a stub library from the headers/code/some list of exported functions. End code will link to the stub library which will load up the dll and fix up the jump table.
Compiler/linker goo includes things like making sure the runtime libraries are where they're needed, making sure that static constructors are executed, making sure that static destructors are registered for later execution, etc, etc, etc.
Now as to your main problem: how do I write extensible code in a dll? There are a number of possible ways - a typical way is to define a pure abstract class (aka interface) that defines a behavior and either pass that in to a processing routine or to create a routine for registering interfaces to do work, then the processing routine asks the registrar for an object to handle a piece of work for it.
On the detail of what you plan to solve, perhaps you should look at an extendible parser like lua instead of building your own.
To your more specific focus.
A DLL is (typically?) meant to be complete in and of itself, or explicitly know what other libraries to use to complete itself.
What I mean by that is, you cannot have a method implicitly provided by the calling application to complete the DLLs functionality.
You could however make part of your API the provision of methods from a calling app, thus making the DLL fully contained and the passing of knowledge explicit.
How do I use the classes and functions in the DLL?
Include the headers in your code, when the module (exe or another dll) is linked the dlls are checked for completness.
Can the DLL call functions from the program linking to it?
Yes, but it has to be told about them at run time.
If I make a class { ... } object; in the DLL, then when the DLL is loaded by the program, will object be available to the program?
Yes it will be available, however there are some restrictions you need to be aware about. Such as in the area of memory management it is important to either:
Link all modules sharing memory with the same memory management dll (typically c runtime)
Ensure that the memory is allocated and dealloccated only in the same module.
allocate on the stack
Examples!
Here is a basic idea of passing functions to the dll, however in your case may not be most helpfull as you need to know up front what other functions you want provided.
// parser.h
struct functions {
void *fred (int );
};
parse( string, functions );
// program.cpp
parse( "a = sqrt(); fred(a);", functions );
What you need is a way of registering functions(and their details with the dll.)
The bigger problem here is the details bit. But skipping over that you might do something like wxWidgets does with class registration. When method_fred is contructed by your app it will call the constructor and register with the dll through usage off methodInfo. Parser can lookup methodInfo for methods available.
// parser.h
class method_base { };
class methodInfo {
static void register(factory);
static map<string,factory> m_methods;
}
// program.cpp
class method_fred : public method_base {
static method* factory(string args);
static methodInfo _methoinfo;
}
methodInfo method_fred::_methoinfo("fred",method_fred::factory);
This sounds like a job for data structures.
Create a struct containing your keywords and the function associated with each one.
struct keyword {
const char *keyword;
int (*f)(int arg);
};
struct keyword keywords[max_keywords] = {
"db_connect", &db_connect,
}
Then write a function in your DLL that you pass the address of this array to:
plugin_register(keywords);
Then inside the DLL it can do:
keywords[0].f = &plugin_db_connect;
With this method, the code to handle script keywords remains in the main program while the DLL manipulates the data structures to get its own functions called.
Taking it to C++, make the struct a class instead that contains a std::vector or std::map or whatever of keywords and some functions to manipulate them.
Winrawr, before you go on, read this first:
Any improvements on the GCC/Windows DLLs/C++ STL front?
Basically, you may run into problems when passing STL strings around your DLLs, and you may also have trouble with exceptions flying across DLL boundaries, although it's not something I have experienced (yet).
You could always load the dll at runtime with load library