GObject vs C ++: What are the benefits of GObj and how does it compare speed / size?

Question

What does it offer an object oriented language like C ++? or is it impossible to use GTK + without it?

Is the implementation of GObject the same as for C ++, in terms of size and speed of the executable file, if both examples use the same compiler? Or are there some trade-offs where a GObject will be slower given the extra features it provides?

Answer 1

GObject (a bit like COM in the Windows world) is a C API designed with language compatibility in mind.

This means that you can use GObjects in any language that supports C function calls, but it makes it difficult to write GObjects in a non-C language that can really be reused from any language (if you write a derived GObject class in say Python, you will need to embed a Python interpreter every time you want to use objects from this class in C).

You can automate the creation of bindings for many languages ​​(for example, Python, Perl, JS, etc.), and here lies one of the strengths of GObject. This explains the somewhat opaque API that GObject provides, which I admit is pretty hard to understand.

Unfortunately, it is also not suitable for C ++. GObjects has no trivial relationship with C ++ classes, and even if bindings are available (Gtkmm), it is not easy to write a C ++ class that inherits from GObject and expose it to the world. You must write C for this.

[What the world needs will be a kind of extension of the C ++ language, which will simplify the interaction with GObject, a bit like C ++ Cx on Windows, but 1) this is a difficult task, possibly achievable through the GCC plugin, and 2) there is no momentum to C ++ in the Gnome world, or in the Linux world in general (KDE is a notable exception). So far, we're tied to Gtkmm bindings.]

Answer 2

The Wikipedia article on GObject includes a comparison with C ++ . Some of the things they mention are the lack of multiple inheritance and the presence of signals. In addition, GObject benefits from the fact that the names of the exported C functions, unlike C ++, are independent of your choice of compiler. Therefore, if you developed an object-oriented library using GObject, it might be easier to link it to C ++.

It would also be interesting to look at Vala , which targets GObject.

Answer 3

Vlad hinted at a little more detailed information about something: The main point in favor of C is that it makes the interaction between compilers or languages ​​“possible” (guaranteed), since it standardizes ABI. This (forgive me if I simplify) allows us to guarantee how callers from any C compiler or other language can use exported characters. Therefore, GTK + has bindings to other languages, including C ++ in GTKmm. The latter is the best of both IMHO worlds: the well-established GTK + API, but with C ++ language features.

C ++ does not yet have an official standard ABI, although it is still not lost, because A-Team is working on it: https://isocpp.org/files/papers/n4028.pdf