Apart from C++, which non-toy languages have direct or easy-to-use compatibility to C? As in "I can take a C library out there, and compile my code against it without having to find, write, or configure some kind of wrapper."
I know that lots of languages have compatibility with C through some form of external call or binding (I've been using bindings in Java, Ruby, Python, etc., so I know it can be done). But you rely on someone (possibly you), to write and maintains a binding for all the libraries you want to use, and the binding has to works on all platforms, etc.
Do more expressive languages than C++ have this feature?
Thanks to all for the mentions of swig or related wrapper-generation tools.
I am aware that those exists, but I don't think they're really as easy as C->C++ integration... but then integrating with C might be the only thing that is easier in C++ ;) )
Objective-C, the bastard child of C and Smalltalk.
Objective-C is a direct superset of C (you can't get more compatible than that), but there are languages which compile to C. Some recent examples would be Vala and Lisaac.
Most statically compiled languages allow interfacing with C libraries. Examples of such languages are Ada, Fortran, Pascal and D. The details are platform and compiler specific; for x86, this basically means supporting the cdecl calling convention.
The D language is compatible with the C ABI. However, it's sometimes non-trivial to convert C header files into compatible D modules. See this page for more details.
Fortran can call C routines, or be called by C. This used to be "platform and compiler specific" as stated in another answer, but Fortran 2003 includes the "ISO C Binding", which makes this part of the language standard and therefore portable rather than platform and compiler specific. The ISO C Binding is supported by numerous Fortran compilers, including gfortran (>= 4.3), Intel ifort, Sun Fortran, etc.
You do have to write an "interface" description of a C routine being called, but it is compiler and platform independent.
For a lot of languages, wrapper code for C libraries are not hard to write - just use SWIG: http://www.swig.org/
While originally written as a quick wrapper generator for Tcl, it now supports:
Tcl, Python, Perl, Guile, Java, Ruby, Scheme, PHP, Ocaml, Pike, C#, Modula-3, Lua, Common Lisp, R and Octave.
If you use any of the language it supports, give it a try. For C functions that deals with strings, integers and floats it is very easy to use. For more complex C functions it obviously gets more complex.
With the right compilers/linkers, name mangling and function arguments, you can link C and Fortran modules. Details here.
Python has a dynamic wrapping module, ctypes, which, while it doesn't eliminate boilerplate binding code completely, does greatly reduce it.
G'day,
You can interface Perl onto C libraries by writing an XS interface between the two. Here's the perlXSTut over at CPAN.
This is how the XML::LibXML and XML::LibXSLT modules are implemented.
You can also interface Ada to C libraries buy means of pragma Import. This is also true for libraries written in C++. And COBOL and FORTRAN BTW.
HTH
cheers,
Related
While developing a new product, we decided to go for a mix of C++ and C#, haven been told that bridging them to allow the C# code to call the C++ code would be easy (spoiler, it's not).
We're pretty experienced C++ programmers and not at all C# programmers so we pretty much just had to believe what we've read. A few attempts to call C and Objective-C was promising and we even found a few articles that showed how to make an unmanaged C++ class available in C# -- or at least we thought. The C++ code in the articles, wasn't C++, but instead the horrible monster C++/CLI that Microsoft seems to think is C++. Since we're doing the C# stuff to get some bits "for free" in macOS and Windows, C++/CLI isn't an option either :-(.
Anyway, plenty of people have claimed that it's easy to call C++ code from some specific programming language, but so far, I haven't seen a single one that will allow me to do so (I haven't been paying too much attention to this, so please provide me with an obvious example). C++ invariably always means C with no C++ stuff at all; no namespaces, classes, no stl, lambdas or anything. Just plain dumb C.
So, are there any languages, besides C++(/CLI) that will allow me to do the following:
Create an instance of a class, using a C++ constructor, and dispatch it with a C++ destructor.
Call member functions on an object ( foo f; f.foo();) with a C++ class.
Use std::vector, std::find_if, std::string and other stuff from the stl. Complete coverage of the stl is not required.
Use overloaded functions (i.e. f(), f(int), f(std::string))
Use overloaded operators (foo operator + (foo, foo))
Use C++11, C++14 and/or C++17 features.
Use RAII (rather important IMHO).
Use namespaces.
No. There is no such language.
Unless you count Objective-C++. But that falls pretty much in the same bucket as C++/CLI, in being C++ with some extensions. And C++/CX is another such beast.
There are some interop tools that can work with C++ classes (SWIG for example), but I have never heard of a tool that is capable of instantiating C++ templates (like vector or find_if) on demand.
What languages will call C++ with no explicit bridging?
The short answer to this question is: NONE
Remember that a programming language is a specification written in some technical report, usually in English. For examples, read n1570 (the spec of C11) or R5RS (the spec of Scheme). For C++, see n3337.
Actually, you are interested in implementations, e.g. in compilers and interpreters for your programming languages. These implementations are practically software. And then the answer might become: it depends (notably on the ABI used & targetted by your compiler and system).
See for examples this list of ABIs for Linux.
plenty of people have claimed that it's easy to call C++ code from some specific programming language,
The C calling conventions are quite common, and it might help to declare every C++ function callable from outside as extern "C". But there is no silver bullet, and details matter a lot.
So, are there any languages, besides C++(/CLI) that will allow me to do the following:
list of C++ features skipped
Probably not.
You probably need at least to understand more about memory management approaches. I recommend understanding more about garbage collection, e.g. by reading the GC handbook (at least for underlying concepts & terminology). Learn more about foreign function interfaces (in some cases, the libffi might help) and language bindings.
You might also consider generating some of the C++ or C glue code, maybe with SWIG (or write your own C++ glue code generator).
On operating systems providing dynamic linking capable of loading plugins at runtime (e.g. Linux with dlopen(3)/dlsym(3); but other OSes often have similar facilities) you could even consider generating some C or C++ glue code at runtime in some temporary file, compile it as a temporary plugin, and dynamically loading that plugin. You could also consider JIT-compiling libraries like GCCJIT or LLVM (or libjit).
I recommend reading SICP, the Dragon Book, and probably Lisp In Small Pieces. Of course, learn something about OSes, e.g. Operating Systems: Three Easy Pieces. Reading about Linkers and Loaders could also help.
As an excellent example of cleverly gluing C++, look into CLASP and see this video.
But whatever approach you take, you'll need a lot of work (years, not weeks).
C++ as a language does not have a defined ABI (Application Binary Interface) - which basically means that there is no universal standard of what a C++ class/function call/template would look like in binary form on any given platform, or across platforms.
What that means is that there is no universal way to call C++ code from other languages, on different platforms, or even across compilers on the same platform. It also means that the people who are telling you "it's easy to call C++ code from XYZ language" are mostly incorrect (or at least incredibly incomplete).
Where there are interfaces it's either because the provider of the interface controls the ABI (C++/CLI with .NET), or because there is a translation layer from C++ to something like the C calling convention (Boost::python).
Some work has been done towards attempting to define an ABI per-platform (http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4028.pdf), but as far as I'm aware it has not yet been accepted into C++17.
You can look into using C++ interpreter, which allows for the fine-grained control you ask for. But I don't know of any that "just works", see also:
Have you used any of the C++ interpreters (not compilers)?
I have written a C++ library to do some numerical analysis. Is there a programmatic advantage to include a C API interface to the library in addition to the C++ API?
Is this isn't an appropriate question for stackoverflow I can delete it.
What has C over C++: a stable well-defined ABI.
There are multiple C++ ABIs (MSVC's and Itanium being the foremost) and each Standard Library implementation (Dirkumware, libstd++ or libc++ for examples) is incompatible with the others. Therefore, the only way for C++ code to correctly link with C++ code is to be compiled with the same compiler (or with compilers sharing the same ABI) and above the same Standard Library implementation.
C, however, is different. C compiled by gcc integrates smoothly with C compiled clang... but it goes well beyond. It integrates smoothly with C++, Python, Haskell, Java, Rust, Lua, Perl, ... most if not all "serious" languages can interact with C more or less smoothly.
So, what is the benefit of a C API over a C++ ? Smooth integration with virtually any programming language under the sun.
Yes, there is one: you need a C API if you would like to call your functions from C code. Unlike the C API, which can called also by your C++ code (extern "C" { ... }), this is not true for C++ API, which can't be call by your C code.
No there is no programmatic advantage to include a C API.
Guess it is down to marketing and what your customers want.
What does it offer to an object oriented language such as C++? or is it not possible to use GTK+ without it?
Is the GObject implementation of objects is of a similar quality to that of C++ in terms of the size and speed of an executable assuming both examples use the same compiler? Or are there some trade-offs where GObject would be slower on the account of additional capabilities it provides?
GObject (a bit like COM in the Windows world) is a C API designed with cross language interoperability in mind.
This means that you can use GObjects in any language which supports calling C functions, but this makes it very difficult to write GObjects in a non-C language which are truly reusable from any language (if you write a GObject derived class in say, Python, you'd have to embed a Python interpreter every time you wanted to use objects from this class in C).
It is possible to semi-automate the creation of bindings for many languages (eg. Python, Perl, JS etc), and here lies one of the strengths of GObject. This accounts for the somewhat opaque API that GObject provides, which is, I confess, quite difficult to understand thoroughly.
Unfortunately, it doesn't fit well within the C++ language either. GObjects have no trivial relationship with C++ classes, and even if bindings are available (Gtkmm) it is not possible to easily write a C++ class "inheriting from GObject" and expose it to the world. You have to write C for this.
[What the world would need would be some kind of extensions to the C++ language which would make it easy to interop with GObject, a little like C++Cx on Windows, but 1) it is a difficult task, perhaps achievable through a GCC plugin, and 2) there is no momentum towards C++ in the Gnome world, or generally in the Linux world (KDE being a notable exception). For now we are stuck with the Gtkmm bindings.]
The article on GObject from Wikipedia includes a comparison with C++. Some of the things they mention is the lack of multiple inheritance, and the presence of signals. Additionally, GObject benefits from the fact that the names of exported C functions do not, unlike C++, depend on your choice of compiler. So if you were to develop an object-oriented library using GObject, it would probably be easier to link with than a C++ one.
It would also be interesting to look at the Vala programming language, which targets GObject.
Just a little elaboration on something hinted by Vlad: A major point in favour of C is that it makes interoptability between compilers or languages 'possible' (guaranteed), in that it standardises an ABI. This (pardon me if I'm oversimplifying) enables guarantees about how callers from any C compiler or other language can use exported symbols. Hence why GTK+ has bindings to various other languages - including C++ in GTKmm. The latter is the best of both worlds IMHO: the well-established API of GTK+ but with the language features of C++.
C++ as yet does not have an official standard ABI, though all is not yet lost, as the A-Team are working on it: https://isocpp.org/files/papers/n4028.pdf
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/).
Is a cfront tool available for the new C++? For any other modern languages?
Comeau C/C++ is a C-generating C++ compiler, like cfront.
What do you mean by “cfront tool”? Cfront was the first C++ compiler. But since failure to add exception support, it has been discontinued. Modern C++ is way beyond the scope of Cfront.
For any other modern languages?
And what do you mean by that? If you mean whether other compilers exist that compile a high-level language into C code then the answer is yes, there are plenty. The Glasgow Haskell Compiler is just one out of many.
I believe a number of languages, at least in their infancy, just "compile" to C code, letting a good compiler (often gcc...) to generate optimized native code. I think GHC is (for some implementations?) such language, and there are some others I don't recall.
I know also lua2c, converting Lua code to C.
Bigloo
Bigloo enables full connections
between Scheme and C programs, between
Scheme and Java programs, and between
Scheme and C# programs.
Gambit-C
Gambit benchmarks