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
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'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.
I'm in the process of writing a C interface to a C++ library, and I'm looking for some high-quality examples (or best practices).
So far this one seems pretty promising: http://czmq.zeromq.org/manual:czmq
Any other suggestions?
You could look into the Parma Polyhedra Library as an example of excellent C interface to a well written C++ library. PPL is a free GPL-ed software, notably used inside the GCC compiler.
Another high quality example is the Open Dynamics Engine. It has a C++ backend and a C frontend. Everything is C linkable.
C++ example
C example
If your C++ library is written as COM on Windows. There are tools to automatically generate the C interface for it.
I can suggest FTGL which is a C++ library providing a C interface. Here are two sample programs that achieve exactly the same thing:
C++ version
C version
Note also that FTGL uses the pImpl paradigm in order to achieve binary compatibility across versions. See here why it's good.
Disclaimer: I'm an FTGL contributor.
libGLU (OpenGL Utility Library) is partially written in C++: http://cgit.freedesktop.org/mesa/mesa/tree/src/glu
libzmq is a kind of weird case since the low-level C API was originally meant to look like POSIX sockets, and absolutely not object-oriented (we made it more consistent and organized over time). Meanwhile the actual library is in C++.
The C++-to-C interface is in libzmq/src/zmq.cpp, and consists of a bunch of simple C functions that call the 'real' C++ code.
CZMQ on the other hand aims for something more classy, providing a simple class model with constructors, destructors, containers, private properties, etc. Nothing radical but does turn C into a much more elegant language.
I'm not sure how well the CZMQ class approach would map to a C++ API unless that API was explicitly designed to be mapped.
Disclaimer: I'm the author of most of CZMQ.
What are my options in terms of a fast functional language for library use in a cross-platform Qt C++ application?
It seems almost all languages (functional or not) have some way of calling C/C++ code in an easy manner. I'd like to go the other way around - write an application in Qt using C++ for stateful business logic, GUIs and stuff but drop down and use a functional language for the core calculation library.
Which ones are easy to use in this manner? Can for instance OCaml code be compiled into a static library and then consumed by a C++ app?
Thanks,
Rickard
Haskell has this capability, though the interaction with Qt/qmake and your build process with ghc may take a little trickery to get working:
http://www.haskell.org/haskellwiki/Calling_Haskell_from_C
There is also a project called HaskellDirect which seems similar to your purpose as well:
http://www.haskell.org/hdirect/
AutoCAD uses AutoLisp so my suggestion would be Lisp.
I'd be tempted to check out qtHaskell and to do the whole thing in Haskell. My opinion is based on Don Stewart's remarkable success doing xmonad in Haskell.
Lisp and Haskell are excellent functional languages but if we consider the ease of binding C/C++ code along with the language, I'd recommend lua.
It is extremely straightforward to bind C functions to lua right off the bat, the interpreter is super compact and easy library to build, it's among the fastest scripting languages out there, and, with luabind, you can easily bind C++ classes, template instantiations, etc. I've had to do bindings for numerous scripting languages in the past and I've never found one that's quite as straightforward as lua. It's also supported with swig if you prefer to bind things through swig which will allow your application to support multiple scripting languages.
From a pure language point of view, the meta-feature/metaprogramming aspect of lua (comparable to lisp) makes it very easy to support all kinds of programming paradigms, though I personally find it best suited for functional programming. It's extremely customizable and well-suited for embedded use.
However, since you are already using qt, qtHaskell might be a nice choice to consider as well.
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/).