Is it possible to build a shared library using Poly/ML?
I want to be able to create a C API for a Poly/ML library, and invoke/load it from different programming languages (e.g., Python). Did anybody try to do that?
I know this can be done in OCaml:
How can I call OCaml functions from a Python program?
Here is an answer provided by David Matthews, Poly/ML main developer (http://www.polyml.org/):
The simple answer is no, at least at the moment. I had a look at this
and wondered if it was possible. The foreign-function interface
allows for call-back functions so there is the mechanism to produce a
C function that when called calls an ML function. The difficulty I
could see was that in order to produce a shared library the closure
for the C function has to be "unpicked" so that relocation information
can be produced for addresses within the closure. I'd have to add
something to libffi to do that. It doesn't look to be too hard for
X86 but I haven't taken it any further. There may be other issues
that I'm not aware of.
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 am wondering what is the best/most common way to create a C++ library that I could create a wrapper for in another language.For example I if I create a library in C++ I'd like to create a wrapper for it in C# and then later on create a wrapper for the C++ library in Python.
I also want to be able to give the library to another person easily almost like a one file thing if that is possible? Also should I use a Dynamic Link Library or a Static Link Library? Extremely new to this sort of thing thanks.
A very common way that people simplify linking C or C++ code to other languages is through the Simplified Wrapper and Interface Generator. For the language runtimes it supports, it's a much easier to understand interface than integrating closely with each different language you wish to ship your library for.
In general, this will mean creating a dynamic library. Loading a dynamic library is a simple task for any runtime, but loading a static module would require modifying the language runtime. For that reason, it simply doesn't make sense to build a static module for either of your cited use cases.
For Python, with your build properly configured, you can ship your library module as a single dynamic library (barring licensing problems with libraries you link to). However, users will typically expect your module to be packaged using the standard Python setup-tools, as a .egg file.
You should be prepared to learn how each respective language community expects third-party packages to be packaged, to make the introduction of your library to them as easy as possible. Conforming to their expectations makes your library appear more professional, better designed, and easier to consider for their projects.
I would recommend, however, spending some time learning more about the Foreign Function Interface of a few different languages, to familiarize yourself with some of the peculiarities that SWIG sometimes can't hide perfectly. For example, passing a value to the other language requires "boxing" the C++ value into a value type, and then incrementing its reference count. SWIG does this for you, but it's sometimes the case where you have no choice but to write or debug some of that code yourself. Being unfamiliar with how those FFI interfaces work will hinder you substantially.
I am new to C++, with some training using fortran95. Trying to convert my knowledge into the new syntax but have run into a snag.
Many of my programs use modules with subroutines, and subroutines within subroutines and use of functions from a library described by NAG.com which are readily available and searchable.
I am currently looking for a c++ version of
http://www.nag.com/numeric/FL/manual/pdf/F08/f08naf.pdf
From what I have read so far, these libraries exist for c++ and I have used some simple ones thus far(like vector, cmath, math.h) but only ones that are already included in my Xcode package for my mac.
I haven't seen anybody mention one of these which my be included with my Xcode, and I am lacking in how to implement outside libraries I find. I am interested particularly in using:
http://www.alglib.net/download.php
Thus far I have been using subrutines as void type functions and simply including them in all of my code. But my code is becoming exceedingly cumbersome and I would like to make something similar to a fortran module to do chebyshev calculations. And I would much rather find a good library of eignevalue calculators and maybe even chebyshev calculators, . . . which I can use.
Essentially my question is, how do I implement external libraries I find and does anybody have a recommendation for a good one? How can I make my own code which contains a callable set of functions and then call it from within another piece of code?
If I understand right, the part of the NAG library you're using in Fortran is basically LAPACK. There is a C interface to LAPACK, called LAPACKE (http://www.netlib.org/lapack/lapacke.html). You can use it in a C++ program.
I didn't understand the other parts of your question.
I know that when you load a dynamic C++ library using dlopen() you can then get pointers to functions inside that library, but is there a way to efficiently (performance matters) do it the other way?
I know that I could just call a function (when initializing the library) inside the library passing an array of pointers to functions, or just send the pointers all separately to a function. (although an array would probably be better because it allows me to add functions yet not require all old plugins to update)
I'm not really sure if this is efficient as there might be hundred functions and sending all of those to maybe 10 libraries might not be efficient.
But I am not very experienced with Dynamic Libraries so I am just wondering if you guys know of any better was to do this.
EDIT: Maybe put all those functions in a class and then send a class pointer trough a function call? Would that work?
"But I am not very experienced with Dynamic Libraries"
That's the cue to say: you don't want to do this.
Perhaps look at Boost Extension (not official part of boost), which takes the high-level, C++ approach here.
That said, most platforms support this to an extent. E.g. XlC++ on AIX has rtld (which requires an explicit 'exported' symbols map, IIRC), and I had the same working on windows and linux (our 3rd-party workflow engine required it). Sending the array of fptrs seems most pragmatic, and closer to the 'plugin' pattern.
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.