I'm working on a C++ project with a large number of classes (150+), each of which has anywhere from 10 to 300 fields or so. I would really like to be able to provide a scripting interface for testing purposes so that I can code callbacks that don't require any re-compilation. I'd like to do this in Lua since I'm more familiar with its C API than I am with Python's, but if it will save headaches I'd be happy to do it in Python.
I've got a solid grasp on how to call Lua functions from my C++ and vice versa, and I know how to pass basic data types back and forth. The question I have is how to share user-specified data types between the two using SWIG.
For example, at some point in my C++, I might want to evaluate a couple of pieces of member data in an object that has 250 fields. I'd like to be able to hand that object off to Lua which could then (hopefully?) use the generated SWIG wrappers to manipulate that object, display certain fields, and then pass the (potentially changed) object back to C++ for continued use.
I would also like to be able to instantiate an instance of the object in Lua using the wrappers and pass it off to C++ to be used as a normal C++ version of the object.
Is this possible? Could somebody point me towards a tutorial or an explicit example?
Thanks for any help you can offer!
As long as you wrap your user-defined types using Swig interfaces (see here for documentation on Swig-Lua API), the interaction should be seamless. The provided Swig wrappers will allow you to instantiate new objects, pass them along to C++ and vice-versa.
I do not believe that Swig-Lua wrapping supports director classes yet, which means that extending existing classes, instantiating them and passing them back to C++ is not possible. Directors are supported for languages such as Python, Java, C# though.
If swig gives you trouble, I've had good luck with the latest version of tolua++, which is for the sole purpose of binding C++ and Lua. It requires a modified .h file as input, which is a bit tedious, but no more so than Swig's modules. I have no reason to prefer one over the other, but it's good to know about both.
You should also check out Luabind. This one implements OOP for Lua and can map classes and data types from Lua back to C++.
Related
I intend to use Squirrel as a scripting language for my C++ application. Naturally, there should be an API for interfacing with the C++ code (for things such as accessing and modifying attributes in my C++ program). This API would consist of a bunch of classes, enums and functions.
While there are utilities like Sqrat that make binding single C++ functions to a Squirrel VM the matter of a single line of code, that is still not satifactory: It would require me to create both the C++ classes with their functions to actually do all the interfacing work, and then I'd have to maintain all the bindings to make those C++ functions known in my scripts as well. My intention is to remove this double maintenance overhead.
So what I want is a tool that would simply take the already existing header file containing all my C++ classes and functions and generate API registration calls from this file. And while we are at it, of course it would be nice to automatically generate a documentation for every function as well (doesn't matter if it's HTML or just a Squirrel script that contains of function definitions + comments or whatever).
I know there's SWIG, but it doesn't have a binding Squirrel, and that's not exactly what I would be looking for anyway - after all, I need to create C++ wraper code, not Squirrel code. I've seen Flex, but I'm not sure whether that's what I'm looking for, either. So is there any tool that would do what I want (automate the creation of wrapper code and API documentation from a C/C++ header)? Otherwise, I guess I might have to write my own little C++ parser that can parse simple function and class definitions.
I'm designing (brainstorming) a C++ plugin framework for an extensible architecture.
Each plugin registers an interface, which is implemented by the plugin itself.
Such framework may be running on relatively capable embedded devices (e.g. Atom/ARM) so I can use STL and Boost.
At the moment I've managed to write a similar framework, in which interfaces are known in advance and plugins (loaded from dynamic libraries) register the objects implementing them. Those objects are instantiated as needed by their factory methods, and methods are called correctly.
Now I want to make it more flexible, having plugins register new interfaces (not just implementing the existing ones) thus extending the API available to the framework users.
I thought of using a std::map<std::string, FunctionPtr>, which is also mentioned by several articles and stackoverflow replies I've read. Unfortunately it doesn't seem to capture the case of different method interfaces.
I feel it might have something to do with template metaprogramming, or traits perhaps, but I can't figure out how it should work exactly. Can anyone help?
Try looking at XPCOM which solves these problems for you - by sortof re-implementing COM.
You have the issue of not knowing what interface the plugin provides to your application, so you need a way for the developer to access it, without the compiler knowing what it is (though, if you supply a header file, then suddenly you do know what it is and you can compile it without any need for plugin unknown-interface fanciness)
so, you're going to have to rely on runtime determinism of the interface, that roughly requires you to define the interface in some way so that the framework can call arbitrary methods on it, and I think the only realistic way you can do that is to define each interface as a set of function pointers that are loaded individually and then stored in data for the user to call. And that pretty much means a map of function pointers to names. It also means you can only user compiler niceties (such as overloading) by making the function names unique. The compiler does this for you by 'mangling' all functions to unique, coded names.
Type Traits will help you wrap your imported functions in your framework, so you can inspect them and create classes that work with any imported type, but it isn't going to solve the main problem of importing arbitrary functions.
Possibly one approach that you'll want to read is Metaclasses and Reflection by Vollmann. This was referenced by the C++ standard body, though I don't know if it will become part of a future spec. Alternatively you can look at Boost.Extension
Maybe the first thing you need check is COM.
Anything that can be done with templates, can be done without, though perhaps in a much less convenient way, by writing "template instances" by hand.
If your framework was compiled without seeing a declaration of class MyNewShinyInterface, it cannot store pointers of type MyNewShinyInterface *, and cannot return them to the framework users. No amount of template wizardry can change that. The framework can only store an pass around pointers to some base class. The users will have to do a dynamic_cast to retrieve the correctly typed pointer.
The same is true about function pointers, only functions have no base classes and one will have to do the error-prone reinterpret_cast to retrieve the right type. (This is just another reason to prefer proper objects over function pointers.)
I've seen similar posts but none that quite asked the question in the same way.
Basically, I've been playing with Shiva3d lately ( http://www.stonetrip.com/ ), which is a 3d engine. The coding inside the engine is in Lua, however, the actual product when exported from the IDE is C++ code. While the coding is restricted, it does a fair job at exporting function, variables and everything back in C++ code.
What I want to know is, can I create a base engine, where there would be a set of predefined class and then use Lua to extend/overload these base classes (by providing certain predefined required functions) and get that code back in C++ with the different Lua/C++ binding libraries that exist?
Have a look at SWIG http://www.swig.org/
It parses the C++ headers and creates binding for several languages (including Lua).
Although I really like SWIG, I fell in love with luabind, because you have more direct control. Additionally it provides a built-in object orientation system and you do not need an additional translator/compiler like swig.
C/C++ can use python API to load py.
But, only simple type is supported.
How can I pass map into py to be a dict with API?
Or, which methods are better?
Use SWIG, which has some ready-made templates for various STL types. See this, for example.
The Python C API supports C-level functionality (not C++ level one) -- basically, you can easily expose to Python things you could put in an extern C block (which doesn't include std::map &c) -- for other stuff, you need a bit more work. The nature of that work depends on what you're using to wrap your C++ code for Python consumption -- there are many options, including the bare C API, SWIG, SIP, Boost Python, Cython, ...
In the bare C API (which I assume is what you're using, judging from your question and tags), I would recommend making a custom object type -- maybe, these days, one subclassing collections.Mapping (MutableMapping if mutable, of course), as you would when implementing a mapping in Python -- and implementing the Mapping Object Structures plus the needed bits of a general type structure such as tp_iter and tp_iternext slots.
Of course, the key idea is that you'll implement item setting and getting, as well as iteration, by simply delegating to your chosen std::map and performing the needed type conversion and low-level fiddling (object allocation, reference counting) -- the latter is the part that higher-level frameworks for extending Python save you from having to do, essentially, but the "wrap and delegate" underlying architecture won't change by much.
I'm writing a graphical application using Objective-C for the front end and C++ for the graphics processing and network communication. I read around on Apple's site looking for a way to link either a .dylib or .so with my C++ code in it to my Xcode project, but nothing seemed to work. I was able to get the project to reference it and link against it, but when I tried to call functions from that .dylib, it was saying that it didn't know what I was trying to do. Does anyone know what is going on here?
I know that Objective-C has all the libraries I would need to do graphics and networking, but I just feel like doing it like this. I haven't done much C++ in a while and I want to learn more Objective-C, so what better way than to use them together?
Thanks,
Robbie
Most of the projects I work on have an ObjC frontend and C++ backend. If you're dealing exclusively with functions, then Dave Gamble's name mangle fix is correct, but if you're dealing with more complex situations, where you need to deal with both ObjC and C++ objects, your best bet is to wrap the C++ objects in ObjC objects. Using opaque references (which is a very fancy way of saying void*), you can actually hand around C++ objects in ObjC and vice versa. I have some sample code that may be helpful.
That said, for graphics you're probably going to take a serious performance hit doing custom C++ rather than using Core Image and the related frameworks. Core Image and the other graphics frameworks are highly optimized for the Mac, and you're very unlikely to do better with hand-rolled C++ (or even very well-written C++ that isn't specifically for the Mac). As you move to 10.6 and grand central dispatch, the performance difference is going to be even more notable because you'll lose all the parallelization advances that you would get for free otherwise. This has nothing to do with ObjC; Core Image is C. You can call it from C++ all you like. I just recommend against custom graphics processing on Mac in any language unless you need portability or you have the expertise necessary to beat Core Image.
You're going to hit one obstacle in the form of what's called "name mangling". C++ stores function names in a way not compatible with Obj-C.
Objective-C doesn't implement classes in the same way as C++, so it's not going to like it.
One way around this is to implement a set of simple C functions which call the C++ functions. It'll be a good challenge to keep the number of C functions as low as possible! You'll end up with a nice compact interface! :)
To declare these functions in a C++ file, you'll need to mark them as C with:
extern "C" int function_name(char *blob,int number, double foo) {...}
This disables the standard name-mangling.
Build a header file with the prototypes for all these functions that you can share with your objective C code.
You won't be able to pass classes around in the same way (because your ObjC code can't use them), but you'll be able to pass pointers (although you might have to lie about the types a little).