I've got a lot of c++ code which contains a lot of functions and classes in namespaces (boost, for example).
Now I'm trying to embed LuaJiT2 as script engine, but I cannot find anything about calling functions and using other stuff from namespaces.
So, Is it possible to pass the functions from c++ namespaces to LuaJIT with the FFI?
You may use the standard Lua API to expose namespace-scope functions, as well as class static functions, to Lua. This is done exactly as you would with the regular Lua interpreter, since LuaJIT is drop-in compatible with it.
But you can't use FFI, because FFI is based on a C-based parsing of the header files. And you're using C++ syntax. FFI is not the only way to use LuaJIT; it's just one that is based on C.
Any of the C++-specific binding APIs that use Lua (Luabind, SWIG, etc) should work just fine with LuaJIT as well.
It is possible to use different name mangling other than C. The reason why its not "common" is because the C++ name mangling is very compiler/platform specific:
http://lua-users.org/lists/lua-l/2011-07/msg00502.html
So this sort of declaration is valid:
ffi.cdef[[
void Test1_Method1(void) asm("_ZN5Test17Method1Ev");
]]
And you can then call Test1_Method1.
Mike Pall has done an amazing job with luajit. So many great features.
Related
I'm writing a few libraries and I want them to be available in C and C++, then wrap them with swig to make them available for Ruby, Python, Java, Lisp, ...
What are the advantages and disadvantages to writing a library in C and then wrapping the library in C++ instead of writing it in C++ and then wrapping it in C?
The only things I can think of would be if the library is written in C++ then C programs might need a C++ compiler to be compiled, though maybe I'm not right on that
There might also be some features or things that don't wrap.
I'm mainly asking for experience, to know what I may run into while doing this project.
Write in C, wrap in C++:
Advantages
If your C code is Object Oriented in some way, or simply doesn't do any macro and similar tricks, making a C++ wrapper should be easy
Actually, you may use SWIG or similar tool to make the C++ wrapper and then use the same artefacts (like SWIG interface file) to make other (Ruby, Python...) wrappers
If you have an idea about the languages you want to interface (say, Ruby and Python, but not Lisp or others) then you may write the C++ wrapper in a way that would make it easier to write wrappers for those languages (even without SWIG)
Disadvantages
One may be caught in making a C++ wrapper which is too C++-ish (with too many templates, for example) which may be very hard to wrap in another language
There are but a few languages that support interfacing C++ directly, especially whole C++. So, you are pretty much required to write a wrapper for other languages.
Write in C++, wrap in C:
Advantages
C is an easier language to interface with, because it is a simpler language and most environments/OSes are written in C.
Actually, if you follow some conventions ("ABI"), most languages provide a way to call into C DLL/.so without any wrapper at all. It is ugly, for the most part, but serves well for simpler interfaces, prototypes, etc.
Disadvatages
Interfacing to C is not as "easy as pie", so may get into trouble if you're not careful. For example, on Windows, to export a function from a DLL you have to mark it "exported", which only has a "de facto" standard way of doing. There are also struct alignment, enum size(s) and other issues.
Interfacing C++ from C is harder than vice versa. You have to make sure your exceptions don't propagate from C++, properly "translate" C++ templates (remember that std::string is a template), various inheritance idioms (interfaces, mix-ins, "regular" multiple inheritance...) in the interface...
My recommendation
I've done both, and my experience suggests that you should write the module in the language that better suits you for the task at hand. When you're done, interface to the other and then wrap to all the rest. Actually, nobody is preventing you from wrapping the C interface from one language (say, Ruby) and c++ from another (say, Python - using Cython).
Interfacing between C and C++ is way easier than interfacing any of them with (almost all) other languages, so should not be a very significant influence in deciding the primary development language.
Suppose I have two projects that I would like to link together:
A C++ library compiled with Visual C++ to a DLL file.
A C++ executable compiled with C++ Builder that uses the classes in the library.
I realize that there is no standard C++ ABI and that any attempts to directly link these two C++ projects together will fail. What is a good, automated way of creating a compatibility layer that allows me to accomplish this?
For example, conceivably the C++ library could expose itself via a C interface. Then the executable would have some C++ classes that wrap the C interface exposed by the C++ library. Since there is a standard ABI for C, it would work.
The only question is how to automatically create the C interface and C++ wrapper classes - manually maintaining this would not be an option. The SWIG project looks promising, but unfortunately, C++ is not one of the exits of SWIG listed on their web site. Is there a way to do what I want with SWIG? Or is there another project other than SWIG that would help me with this task?
Or am I going about this the wrong way?
Edit: The core C++ library is intended to be cross-platform. The executable, obviously, is Windows-specific. I don't want to pollute the core library to the extent that it becomes impossible to compile it on other platforms.
If it only has to run on Windows, I would expose the classes as COM objects. They'll still be in a DLL and they can be used by any language which understands COM.
The "standard" way of doing this, in Windows, is to use COM objects. So, that is certainly a good option to look at. In Linux systems, the module interaction model (e.g., executable-DLL interaction) is very different, and ABIs exist for C++.
If you would want to do this manually (create your own COM-like library), it can be a lot of work with many little tricky issues to take seriously. You'll need a cross-module RTTI system, you'll need an interface query/definition protocol, some mechanism to manage memory across modules, etc. Beyond that, to "automate" it, you will probably need a combination of MACROs and template meta-functions.
One cross-platform option that I would highly recommend that you consider or at least look at is using Boost.Python and the Python language as the "glue" between your modules. The Boost.Python library basically does the whole "automated exporting / importing of classes", but it exports your C++ classes and functions as Python classes and functions. And, it is completely non-intrusive and cross-platform, so this is really an ideal example of automated exporting. So, you might consider using Python to write your high-level glue-code, or using Python as an intermediate between the C++ modules, or even reworking the Boost.Python library to use only the "automated exporting" mechanisms to export to whatever interface system you design or use.
I'm sure there a plenty other similar libraries out there. But the number one question is, of course, do you really need this? You might be using a bazooka to kill a fly.
Why not just compile the library with C++ builder as well?
Looking around at swig (I knew swig should be able to wrap C++ in C):
SWIG and C++
If core library is cross-platform why not also write the UI as a cross-platform Qt application and build everything in Visual C++ on Windows.
if i have written a library in C++, and have bindings for C, Ada, Fortran, D & other compiled languages.
could all these bindings be in the same binary with the C++ compiled code even if they use the same function names?
and could you use the bindings like this?
Depending how you create your bindings a library may not be even necessary:
Bindings written some interpreter specific APIs:
For example, ruby extensions written using the MRI API, are basically a shared library providing a:
void init_Modulename()
This function then uses the MRI api like rb_define_module, rb_define_class, rb_define_method, etc to wrap the C/C++ APIs. Make sure this function is surrounded by extern "C" so it's name does not get mangled in the C++ way.
Normally this shared library goes linked against the library you are binding, but nothing prevents that they are the same shared library.
Bindings done at runtime
For example bindings using FFI on Ruby and other interpreters. The bindings get defined in the same language and it is the FFI library that knows how to call the methods in the target library at runtime. Therefore in this case the bindings themselves have no "library".
Bindings done with generators
If you use a generator, like SWIG, it will scan the library headers and generate the bindings for various languages. Depending on how those targets are implemented by the SWIG generator (for example, for Ruby uses the MRI API described above) then SWIG will create code you can compile into its own library, but as long as you don't have symbol conflicts, you could as well compile this together with your library.
When I mean symbol conflicts, I don't mean the API itself, but the binding helpers, like init_Modulename().
You can link C++ with C, provided you are only calling C style functions (outside of objects) and have turned name mangling off in the header via "extern C". Especially if you are using the same compiler. Different compilers will cause problems if they use different obj formats. I don't know about ADA/Fortran/D, but I suspect the answer will be no, at least directly via .LIB or .OBJ files. On windows, you can try via DLL's if ADA/FORTRAN/D supports dynamic linking (or you can call the windows api LoadLibrary).
This is not an easy thing to do and I glossed over the details. If you are really going to try, then you'll need to be specific about which platforms and compilers you are using and I'll try to be more specific.
Yes. An example (slightly reversed) is PlPlot; it's written in C and has bindings to Ada, C++, D, Fortran77, Fortran95, Java, Lua, OCaml, Python, ...
Are there any high level language that don't support using C++ libraries?
Using C++ libraries from other high-level languages has a couple of major obstacles:
if the library is OO, you need to be able to create a C++ object in the calling language - this is not easy.
C++ implementations use a technique known as "name-mangling" to ensure type-safe linkage. Unfortunately, there is no standard for name mangling, so C++ code cannot even easily be called between different C++ implementations.
So the answer to your question is that most HLLs will have problems calling C++ code. They may also have problems calling any other language of course - there are actually no standardised binary interfaces between languages, except ad hoc, platform-specifc ones.
I can't think of any language that is able to use C++ libraries directly. Even getting C++ to do it can be tricky (if the library was compiled with a different compiler than you're using)
Of course, if you write a wrapper of some kind (either a wrapper for the specific library, or some kind of bindings library that lets you expose specific types), then any language can use C++ libraries. But directly, as-is, with no extra work? I don't think any language other than C++ can do it.
This is a bit of an anti-answer, but many popular high-level languages can have bindings to C++ library code created for them via swig (http://swig.org/).
I am an experienced C/C++ developer but I am a novice in Ruby.
How can I call a C++ function from with in Ruby?
You have 3 possibilities :
1) Ruby is able to load libraries. Even if it is a bit tricky, you can decide to write your own loader and bind your C++ library in Ruby.
This is done using what is called an extension module. You will find a comprehensive tutorial here: http://www.rubyinside.com/how-to-create-a-ruby-extension-in-c-in-under-5-minutes-100.html
2) You can use a tool that will generate the Ruby wrapper around your C++ library. Look at SWIG for example (http://www.swig.org/).
You just have to create a file in a swig-specific syntax and provide it to SWIG. It will then be able to generate the wrapper for many languages, Ruby included.
3) You can choose to use a middleware, such as CORBA/ICE/whatever. It may be a bit overkill if you only want to call some C++ functions, but it will allow you to remote call the functions, or "hide" a grid behind the middleware.
To call C++ code from Ruby, you will likely want to build an extension.
If you are an experienced C++ developer, you may feel comfortable with Rice:
https://github.com/jasonroelofs/rice
It uses C++ metaprogramming techniques to simplify writing extensions.
If you were calling into C, you could also use ffi. Calling C++ code is a little more complicated than calling C code due to name mangling and exceptions.
I believe the questioner is asking how to call C++ from with in Ruby, if so then the for simple C/C++ RubyInline1 is by the far the simplest solution.
Alternatively if you need to call more substatntial C++ code, you can build a ruby extension. Here is a good tutorial
You need to wrap your c++ code in a C interface and then bind those C functions to ruby methods using rb_define_method()
alternatively you can use SWIG, as Aurelien said.