My general question is this: what's the most common way to include libraries in other languages in a C application?
For example, if I have a Ruby library intended for doing function X, and a Python library for doing function Y, how can I write a program in C (the language, that is) that uses the functions in each?
I've seen wrappers that give access to C libraries in these higher languages, but are there wrappers that go the other way? Is there a common way of handling this in general?
Are these native-code libraries (i.e. have they been compiled?) Or are these source libraries (i.e. a bunch of text files containing Ruby source code)?
If the former, libraries in a language like Ruby or Lua or so usually have a published binary interface ("ABI"). This is low-level documentation that describes how their libraries and its functions work under the hood. Often, those are defined in C or C++, or whatever language was used to implement the interpreter/compiler for Ruby itself.
So you'd have to find that documentation, and find out how to call the parts you are interested in. Some languages even use the same ABI as C does, and you just need to create a header file that matches the contents of the library and you can call it directly (This is how you integrate e.g. assembler and C, or even C++, which you can get to generate straight C functions).
If the latter, you usually need to find an embeddable version of the language, and find out how to run a script from inside your application (This is how Lua is usually used, for example).
But are you sure you need the given Ruby libraries? Often, common libraries are implemented using a C or C++ library under the hood, and then just wrapped for scripting languages, so you can just skip the scripting translation layer and use the (maybe slightly more low-level) library yourself.
PS - there are also automatic wrapper generators, like SWIG, that will read a file in one language and write the translation code for you.
Related
I'm writing a standard library for my programming language which is compiled to LLVM IR. I've also stumbled upon this interesting post Custom Programming Language ~ How to interact with the Operating System but I'm stuck on implementing interaction with the filesystem.
My language is quite similar to C, so I will use C for examples.
In C we have a struct called FILE and we can pass it to fopen, fclose etc...
How can I implement this datatype myself? Do I just create a struct with similar fields and it will work?
How do popular LLVM-based languages implement this? For example Jai, Zig, Swift ...
Generally, you pick the smallest possible base platform and then define matching function and struct types for that interface only. For example, "my language only works on linux for now and my platform is those syscalls I need, and no more" or "my language only uses the exported symbols in this C library that I write myself". I've seen both. The goal is to have a small cross-language interface.
The kernel will use lots of code, the C library may use lots of other libraries or the kernel, but the cross-language interface is kept small, since cross-language calls/types are so ticklish.
I've looked for C APIs, but I've only found C++ API's that can't be used inside a C code.
Are there any C (not C++ or C#) APIs or another way for using AMPL in a C code?
There being no C API for AMPL as far as I can tell, your best bet is to write C++ wrappers for the tasks you want to perform, assigning them C linkage (extern "C") and building them with a C++ compiler. Done correctly, these will be callable from C code. The C code will not be able to handle AMPL objects directly, however, so your wrappers will need to perform some kind of data marshaling in both directions.
I do recommend wrappers specific to your particular tasks, as opposed to generic wrappers for the whole API. I suspect that you would find the latter a much larger and more difficult task.
I am implementing a proof of concept application for source-to-source transformation and need a C-parser with an API for manipulating/traversing the C-syntax tree (AST).
I have tried to use clang but I ran into various problems, like not being able to compile the tutorials using libclang, wrong architecture etc. Since this is a proof of concept application, I will defer clang to a different date.
Question
What are some software/libraries (implemented in any language) which can parse C code and which provide an API so I can build applications on top of them. I looked around, but I could not locate any free parsers.
The platforms I can use are anything on Windows or Mac or Linux, and any parsers written in C/C++/Java/Perl/Python/PHP will work.
You could try one of the available grammars for ANTLR. ANTLR has support for creating tree walkers and you can walk/manipulate the AST manually if necessary. ANTLR V3 has several grammars available including a C preprocessor, ANSI C and GNU C.
The GObject Reference Manual states that the GObject system was designed to export functions written in C to other languages by using some generic glue code. It is also noted that this glue exists for perl and python explicitly. Omitted however, is how exactly where to find and how to use it.
So, lets suppose I have written a new GObject (for the sake of simplicity, the example given in the same manual) complete with C sources and header files, compiled it, and appropriately installed it, locating it where system libraries are to be found. Now I want to instantiate and use the object in a Python program. Or a Perl Program. Or even a Java program. Or any other programming language that has glib bindings available. How exactly can this be done?
Note that I want to use the object directly, most probably through the already existing generic glue code. I am aware of the possibility to use DBus to export the object from a running C program and access it with Python. But I look for no IPC-Solution. Compiled C library objects shall be more or less directly exported to another programming language.
You're looking for GObject Introspection. Once you have that set up properly you can use PyGObject (Python), Gjs (JavaScript), Vala, etc. pretty easily.
All the languages are, obviously, different, but since you sound most intested in Python... the Python GTK+ 3 Tutorial explains the process using GTK+ as an example.
Here's a few examples below. GType and GObject are standards and do not provide the glue code. You'll just want to look for the language you want to use and see if anyone has implemented the glue yet. If not, maybe you can :)
https://wiki.gnome.org/PyGTK/WhatsNew28
http://search.cpan.org/~rmcfarla/Glib-1.020/GType.xs
I want to write a wrap for a DLL file, in this case for python. The problem is that the argument types are not the C standard ones. They have been typedef'end to something else.
I have the header files for the DLL files... so I can manually track the original standard C type the argument type was typedef'ined to. But wanted a more systematic way to do this. I was wondering whether there is a utility that would evaluate the header files, or if you can get somewhere in the dll the types definition.
I think the tool you are looking for is SWIG:
SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is used with different types of languages including common scripting languages such as Perl, PHP, Python, Tcl and Ruby. The list of supported languages also includes non-scripting languages such as C#, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), Java, Lua, Modula-3, OCAML, Octave and R. Also several interpreted and compiled Scheme implementations (Guile, MzScheme, Chicken) are supported. SWIG is most commonly used to create high-level interpreted or compiled programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG can also export its parse tree in the form of XML and Lisp s-expressions. SWIG may be freely used, distributed, and modified for commercial and non-commercial use.
This does assume that you are willing to use the headers for the DLL. If you want to work solely with the DLL, then you have more work to do. It might provide a reflection interface that you can use to analyze the types. Failing that, you are into a world of pain - or reverse engineering any debugging information in the DLL.