I'm working on rust right now because we want to switch to this technology. Today we only use c/c++. For me now the question arises, if it is possible to provide a library in rust, just like in c/c++. Of course I have seen several examples where rust library is called from c and vice versa. But my question aims at another use case. It is about an API that has a state and not just a stateless function. For example you would have to use an init function to create an object pointer which is returned to the caller. Any other function need this object pointer to provide the needed functions. I would be very surprised if this is not possible but unfortunately I have not found anything. In our Use Case we want to offer the API ( written in rust ) for c++, swing and Kotlin. Of course I know that I could also write this API in c/c++ but the use case relies on Rust for various reasons.
Thanks for your tips
Greeting
Dusan
Translated with www.DeepL.com/Translator (free version)
Related
So for the past few hours I've been trying to figure out how to use C++ classes contained in static (or dynamic) libraries from within Lua. I've found several packages, such as LunaFive or SimpleCppBinding, but I seem not to understand how to use them properly. From what I see there's a main function, therefore I guess it's not a library, but an executable which I run and then run the Lua script, which will hook the app and get the class, or something? What I basically want to do is:
create a library containing, for example, a class 'Player' in C++
modify this library to be usable from Lua
somehow use this class and it's methods from within the Lua in the same way as if it would be a Lua class
Is such thing even possible? And if so, could someone explain how such thing can be done?
I'm currently on Windows, but I can do it on Linux as well. On windows I'm using VS, on Linux I'd be using CLion paired with g++. Lua 5.3.
I'm not sure if this is somewhat relevant, but I'm developing a game-mode for FiveM (GTA V multiplayer client). The FiveM comes with a Lua support for scripting by default, but I'd love to use some of the C++ standard libraries and features. Therefore I'd really love to create some libraries for the server in C++, and then use them from within the Lua supplied by FiveM.
Static library: not possible. Your options are: 1. a dynamic library (binary) with some kind of interface accessible by Lua executable (Alien, Lua-specific hooks....) or 2. A custom executable which includes the Lua engine and the C++ stuff with some glue. Your examples with the 'main' function probably are the latter type.
Lua was designed, from the beginning, to be integrated with software written in C and other conventional languages. This duality of languages brings many benefits. Lua is a tiny and simple language, partly because it does not try to do what C is already good for, such as sheer performance, low-level operations, or interface with third-party software.
-Preface
I understand your pain, however Lua simply isn't meant to be used the way you intend, it's actually built to be used the other way around.
The closest thing I can think of to get the result what you want is to have a host C++ application from which you immediately create a lua state and push results of the functions you called from the C++ program into the stack, in return can be used in your Lua script and processed.
If this is something you might be able to adjust to, here is a great starting point
I recently asked this question https://softwareengineering.stackexchange.com/questions/129076/go-instead-of-c-c-with-cgo and got some very interesting input. However there's a mistake in my question: I assumed cgo could also be used to access c++ code but that's not possible. Instead you need to use SWIG.
The go faq says "The cgo program provides the mechanism for a “foreign function interface” to allow safe calling of C libraries from Go code. SWIG extends this capability to C++ libraries. "
my question:
Is it possible to access high-level c++ frameworks such as QT with SWIG + Go and get productive? I'd like to use Go as a "scripting language" to utilize c++ libraries.
Have you any experience with go and swig? Are there pitfalls I have to be aware of?
Update/Answer: I've asked this over IRC too and I think the question is solved:
SWIG is a rather clean way of interfacing c++ code from other languages. Sadly matching the types of c++ to something like go can be very complex and in most cases you have to specify the mapping yourself. That means that SWIG is a good way to leverage an existing codebase to reuse already written algorithms. However mapping a library like Qt to go will take you ages. Mind it's surely possible but you don't want to do it.
Those of you that came here for gui programming with go might want try go-gtk or the go version of wxWidgets.
Is it possible? Yes.
Can it be done in a reasonably short period of time? No.
If you go back and look at other projects that have taken large frameworks and tried to put an abstraction layer on it, you'll find most are "incomplete". You can probably make a fairly good start and get some initial wrappers in place, but generally even the work to get the simple cases solved takes time when there is a lot of underlying code to wrap, even with automated tools (which help, but are never a complete solution). And then... you get to the nasty remaining 10% that will take you forever (ok, a really really long time at least). And then think about how it's a changing target in the first place. Qt, for example, is about to release the next major rewrite.
Generally, it's safest to stick to the framework language that the framework was designed for. Though many have language extensions within the project itself. For example, for Qt you should check out QML, which provides (among many other things) a javascript binding to Qt. Sort of. But it might meet your "scripting" requirement.
A relevant update on this issue: it is now possible to interact with C++ using cgo with this CL, which is merged for Go 1.2. It is limited, however, to C-like functions calls, and classes, methods and C++ goodies are not supported (yet, I hope).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm getting a little rusty in scripting languages, provided they're popping like mushrooms lately :)
Today I thought that it would be nice to have a scripting language that talks seamlessly to C++, that is, could use C++ classes, and, the most important for me, could be compiled into C++ or some DLL/.SO (plus its .h) so that I could link it into my C++ program and make use of the classes the script defines or implements.
I know I could embed any popular scripting language such as lua, ruby, python... but the interface usually includes some kind of "eval" function that evaluates the provided scripting code. Depending on the tool used to couple C++ and the scripting language, the integration for callbacks of the script into C++ could be more or less easy to write, but I haven't seen any scripting language that actually allows me to write independent modules that are exposed as a .h and .so/dll to my program (maybe along the lines of a scripting language that generates C++ code).
Do you know any such tool/scripting language?
Thanks in advance.
PD. I've been thinking along the lines of Vala or Haskell's GHC. They generate C, but not C++...
UPDATE 2020: Today I would probably go with Lua + Sol2/3 except if I really want to avoid Lua as a language. Chaiscript becomes a good candidate in this case though it is not optimal performance-wise compared to Lua+Sol2/3 (though it was greatly improved through years so it is still good enough in many cases).
Falcon have been dead for some years, RIP.
The following ones are more C++ integration oriented than language bindings :
ChaiScript - trying at the moment in a little project, interesting, this one is MADE with C++ in mind and works by just including a header! Not sure if it's good for a big project yet but will see, try it to have some taste!
(not maintained anymore) Falcon - trying on a big project, excellent; it's not a "one include embed" as ChaiScript but it's because it's really flexible, and totally thought to be used in C++ (only C++ code in libs) - I've decided to stick with it for my biggest project that require a lot of scripting flexibility (comparable to ruby/python )
AngelScript - didn't try yet
GameMonkey - didn't try yet
Io - didn't try yet
For you, if you really want to write your scripting module in C++ and easily expose it to the scripting language, I would recommand going with Falcon. It's totally MADE in C++, all the modules/libraries are written that way.
The question usually asked in this context is: how do I expose my C++ classes so they can be instantiated from script? And the answer is often something like http://www.swig.org/
You're asking the opposite question and it sounds like you're complicating matters a bit. A scripting engine that produced .h files and .so files wouldn't really be a scripting engine - it would be a compiler! In which case you could use C++.
Scripting engines don't work like that. You pass them a script and some callbacks that provide a set of functions that can be called from the script, and the engine interprets the script.
Try lua: http://www.lua.org/
For using C++ classes in lua you can use:
To generate binding use tolua++: http://www.codenix.com/~tolua/
It takes a cleaned up header as input and outputs a c file that does the hard work. Easy, nice and a pleasure to work with.
For using Lua objects in C++ I'd take the approach of writing a generic Proxy object with methods like (field, setField, callMethod, methods, fields).
If you want a dll you could have the .lua as a resource (in Windows, I don't know what could be a suitable equivalent for Linux) and on your DllMain initialize your proxy object with the lua code.
The c++ code can then use the proxy object to call the lua code, with maybe a few introspection methods in the proxy to make this task easier.
You could just reuse the proxy object for every lua library you want to write, just changing the lua code provided to it.
This is slightly outside my area of expertise, but I'm willing to risk the downvotes. :-)
Boost::Python seems to be what you're looking for. It uses a bit of macro magic to do its stuff, but it does expose Python classes to C++ rather cleanly.
I'm the author of LikeMagic, a C++ binding library for the Io language. (I am not the author of Io.)
http://github.com/dennisferron/LikeMagic
One of my explicit goals with LikeMagic is complete and total C++ interoperability, in both directions. LikeMagic will marshal native Io types as C++ types (including converting between STL containers and Io's native List type) and it will represent C++ classes, methods, fields, and arrays within Io. You can even pass a block of Io code out of the Io environment and use it in C++ as a functor!!
Wrapping C++ types up for consumption in Io script is simple, quick and easy. Accessing script objects from C++ does require an "eval" function like you described, but the template based type conversion and marshaling makes it easy to access the result of executing a script string. And there is the aforementioned ability to turn Io block() objects into C++ functors.
Right now the project is still in the early stages, although it is fully operational. I still need to do things like document its build steps and dependencies, and it can only be built with gcc 4.4.1+ (not Microsoft Visual C++) because it uses C++0x features not yet supported in MSVC. However, it does fully support Linux and Windows, and a Mac port is planned.
Now the bad news: Making the scripts produce .h files and .so or .dll files callable from C++ would not only require a compiler (of a sort) but it would also have to be a JIT compiler. That's because (in many scripting languages, but most especially in Io) an object's methods and fields are not known until runtime - and in Io, methods can even be added and removed from live objects! At first I was going to say that the very fact that you're asking for this makes me wonder if perhaps you don't really understand what a dynamic language is. But I do believe in a way of design in which you first try to imagine the ideal or easiest possible way of doing something, and then work backwards from there to what is actually possible. And so I'll admit from an ease-of-use standpoint, what you describe sounds easier to use.
But while it's ideal, and just barely possible (using a script language with JIT compilation), it isn't very practical, so I'm still unsure if what you're asking for is what you really want. If the .h and .so/.dll files are JITted from the script, and the script changes, you'd need to recompile your C++ program to take advantage of the change! Doesn't that violate the main benefit of using script in the first place?
The only way it is practical would be if the interfaces defined the scripts do not change, and you just are making C++ wrappers for script functions. You'd end up having a lot of C++ functions like:
int get_foo() { return script.eval("get_foo()"); }
int get_bar() { return script.eval("get_bar()"); }
I will admit that's cleaner looking code from the point of view of the callers of the wrapper function. But if that's what you want, why not just use reflection in the scripting language and generate a .h file off of the method lists stored in the script objects? This kind of reflection can be easily done in Io. At some point I plan to integrate the OpenC++ source-to-source translator as a callable library from LikeMagic, which means you could even use a robust C++ code generator instead of writing out strings.
You can do this with Lua, but if you have a lot of classes you'll want a tool like SWIG or toLua++ to generate some of the glue code for you.
None of these tools will handle the unusual part of your problem, which is to have a .h file behind which is hidden a scripting language, and to have your C++ code call scripts without knowing that that are scripts. To accomplish this, you will have to do the following:
Write the glue code yourself. (For Lua, this is relatively easy, until you get into classes, whereupon it's not so easy, which is why tools like SWIG and toLua++ exist.)
Hide behind the interface some kind of global state of the scripting interpreter.
Supposing you have multiple .h files that each are implemented using scripts, you have to decide which ones share state in the scripting language and which ones use separate scripting states. (What you basically have is a VM for the scripting language, and the extremes are (a) all .h files use the same VM in common and (b) each .h file has its own separate, isolated VM. Other choices are more complicated.)
If you decide to do this yourself, writing the glue code to turn Lua tables into C++ classes (so that Lua code looks like C++ to the rest of the program) is fairly straightforward. Going in the other direction, where you wrap your C++ in Lua (so that C++ objects look to the scripts like Lua values) is a big pain in the ass.
No matter what you do, you have some work ahead of you.
Google's V8 engine is written in C++, I expect you might be able to integrate it into a project. They talk about doing that in this article.
Good question, I have often thought about this myself, but alas there is no easy solution to this kind of thing. If you are on Windows (I guess not), then you could achieve something like this by creating COM components in C++ and VB (considering that as a scripting language). The talking happens through COM interfaces, which is a nice way to interop between disparate languages. Same holds for .NET based languages which can interop between themselves.
I too am eager to know if something like this exists for C++, preferably open source.
You might check into embedding Guile (a scheme interpreter) or V8 (Google's javascript interpreter - used in Chrome - which is written in C++).
Try the Ring programming language
http://ring-lang.net
(1) Extension using the C/C++ languages
https://en.wikibooks.org/wiki/Ring/Lessons/Extension_using_the_C/C%2B%2B_languages
(2) Embedding Ring Interpreter in C/C++ Programs
https://en.wikibooks.org/wiki/Ring/Lessons/Embedding_Ring_Interpreter_in_C/C%2B%2B_Programs
(3) Code Generator for wrapping C/C++ Libraries
https://en.wikibooks.org/wiki/Ring/Lessons/Code_Generator_for_wrapping_C/C%2B%2B_Libraries
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).
I need to build a C++ library to distribute among our customers. The library must be able to be accessed from a wide range of languages including VB6, C++, VB.net and C#.
I've being using ActiveX controls (ocx files) until now. But I wonder if there is a better kind of library (dll, etc.) that I can build. What do you recommend?
I'm limited to C++ as the library language, but you can mention other languages for reference to other developers.
P.S. Sorry if the question was already asked. I had some trouble finding a suitable title. Feel free to correct my English.
Edit: Seems like the best choice is either DLLs or OCX (i.e., COM), but I'm still having some doubts on which one will I choose. Which one is more suitable to modern languages (.NET for instance)? Which one would be easier to use from an end developer perspective?
Almost every language has a way of loading dynamic libraries and accessing exported C functions from them.
There is nothing preventing you from using C++ inside the dll but for maximum portability, export only C functions.
I have some more about this in this post.
If you're looking at supporting both VB6 and .NET, you're pretty much stuck with exposing interfaces via COM, but at least that'll get you out of having to create more than one wrapper based on the language/runtime system you're trying to interact with.
If there is any chance this will need to be ported to non windows platforms then a DLL / Shared library is your best choice as a COM object really isn't at all portable.
In addition you can call a DLL from almost any platform even if it requires you to write a wrapper of some kind. It's pretty easy to wrap a dll in a com object but if you make a native com object it's a lot harder to add a C style DLL API. Plus you might want to call it from java for example and it's much easier to write a JNI wrapper to call your DLL than get it working with COM in any kind of cross platform way.
Really it depends on what platforms you really need to call it from and how certain you can be that you won't get something out of the ordinary in future.
To be callable from all those languages your only real option is going to be COM, without having to write wrappers where required (which would defeat the point)