10

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?

Mykola
  • 3,343
  • 6
  • 23
  • 39

3 Answers3

9

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.]

AndyG
  • 39,700
  • 8
  • 109
  • 143
Alexandre C.
  • 55,948
  • 11
  • 128
  • 197
  • 1
    The "glue problem" exists when bridging between any OO system to another, regardless of originating language (yes, some have better libs available than others). As versions change, stub generators like SWIG must be maintained. Even with LLVM's vmkit project, the world is far from any sort of object system standardization. If it weren't hard work, it wouldn't be worth getting paid a decent wage to work on it then would it? :-) – mda Jul 14 '12 at 01:31
  • 1
    Why automated binding creation can't work with C++ like it works with other languages, such as Python, Vala, Javascript? – cfa45ca55111016ee9269f0a52e771 Feb 20 '13 at 12:10
  • 1
    @fr33domlover: because in these dynamic languages, bindings are done at runtime. Providing a C++ compiler with the relevant information to generate the glue code is difficult. – Alexandre C. Feb 20 '13 at 19:56
  • Vala is a statically typed language with compile-time bindings. In theory you could generate C++ bindings from the GObject Introspection data, but glibmm is much older the GI and doing so would likely require API/ABI breaks. – nemequ Nov 18 '15 at 17:47
4

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.

Christian
  • 499
  • 6
  • 24
Vlad
  • 18,195
  • 4
  • 41
  • 71
2

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

underscore_d
  • 6,309
  • 3
  • 38
  • 64