30

The Introduction

Okay, so after version 0.60 of GTK+, the designers realized that for future development and progress, the entire toolkit needed to be rewritten to be object-oriented.

Now, since C doesn't support OOP, to provide object-orientation and in inheritance heiriearchies, they created the GObject System. Now creating the GObject System must have required development time, more dependencies, more problems, but they had to create it to provide object orientation capabilities to the C Programming Language. But at that time, there was another solution that provided exactly that, C++!

The Question

Why didn't the developers of GTK+ just use C++?

The Explanation

I mean, Why waste time creating an entire library instead of using a time-tested solution adopted by a lot of projects? Don't get me wrong, I am not trying to turn this post into a C vs C++ thing (I've had enough of that on forums, thank you). I just want to know the reasons and issues that made the designers of GTK+ make the decision they did.

ApprenticeHacker
  • 21,351
  • 27
  • 103
  • 153

4 Answers4

25

I can't directly answer the question, at least as far as GTK goes. That answer lies with the GTK+ developers, so you'll have to hunt them down and ask them. But as for why one would want to add an object oriented system to C, instead of using C++, there are plenty of reasons. The three I would immediately think of are

  1. Language Complexity: While C is a pretty simple language, C++ is mind-numbingly complicated, with support for most (not all) C stuff, as well as conveniences like references, and also object-oriented features and a complex template language. And have you seen the new system of values: lvalues, rvalues, glvalues, prvalues and xvalues - huh? There's plenty more I could talk about. Given time, C++ becomes manageable, but it's still overkill for just wanting some object oriented features in C.

  2. Control: If the designers went with C++, they'd be stuck with C++ philosophy. For instance, multiple inheritance is a controversial idea, and for good reason. By design, the GObject system is built to only support single inheritance, which can drastically simplify the inheritance hierarchies. If the designers went with C++, there would be no way to limit users to a single inheritance system. Multiple inheritance is just an example - I'm sure there's plenty of other places in which the GObject system differs from the C++ ideology.

  3. Interoperability: This is probably a big one. Although there a few languages with which C++ interoperates cleanly, the fact is that C++ just isn't that great at interop. However, interoperability with C is almost taken for granted. C is often described as the lingua franca of programming languages, since it forms the de facto standard for interop. By designing a C API, the GObject designers opened the door to GTK+ development in any number of languages.

Ken Wayne VanderLinde
  • 18,915
  • 3
  • 47
  • 72
  • 9
    @NicolBolas The answer represent possible line of thought of or choices faced by GTK developers `before` they developed GTK. Like the answerer mentions, the `answer lies with the GTK+ developers.` – user1055604 Mar 17 '12 at 06:24
  • 2
    I believe #3 was particularly attractive. Bindings for C++ can be done, but the situation have always been slightly better for C. – Rawler Mar 17 '12 at 21:05
  • 3
    @NicolBolas: Either answer the question or don't, but your snide comments aren't helping anyone. – Lightness Races in Orbit Mar 18 '12 at 10:31
  • 1
    The simple answer : C++ does NOT define an ABI ( application binary interface ) whereas C does. Hence, C based GObject. Microsoft built COM for the same reason. – kert Apr 11 '14 at 21:17
  • `While C is a pretty simple language, C++ is mind-numbingly complicated` GObject is much harder than C++ (I know and use both) simply because its type system isn't statically checked, and you have to use oodles more boilerplate. Anyway, it may as well be its own language (it has its own garbage collection and OOP semantics--it is an object system after all)--most common plain-C libraries have a gobject library for which bindings are manually maintained. – weberc2 Aug 06 '14 at 18:33
  • 3
    `For instance, multiple inheritance is a controversial idea, and for good reason. By design, the GObject system is built to only support single inheritance, which can drastically simplify the inheritance hierarchies.` Also a bunk reason; why would they care if users use MI or not? It wouldn't affect their project (GIMP) and there's nothing about C++ that _forces_ you to use MI. Just don't do it if you don't like it (that's my philosophy, and I've never run into problems). – weberc2 Aug 06 '14 at 18:35
  • `Interoperability` C++ can be externed to C. Check out `libclang` for a really good example. These three comments are why I -1'd this answer. It's one of the most highly voted, accepted, misinformative answers I've seen on SO. – weberc2 Aug 06 '14 at 18:37
  • @weberc2 "might as well be its own language" - I'm not sure, but I'm pretty sure that's called Vala :) In any case, that's a fair point. – Ken Wayne VanderLinde Aug 06 '14 at 18:37
  • @KenWayneVanderLinde I know Vala and use it once in a while when I get frustrated with plain GObject. Then I get frustrated with Vala and go back to plain GObject. Sometimes I get frustrated with both and revert to Qt. Then I get frustrated with Qt's meta-object/black-magic type system and go back to GObject... :( – weberc2 Aug 06 '14 at 18:41
  • @weberc2 About MI: The reason a designer cares about whether users will use MI or not is that MI requires extra design effort since there do exist real problems with it, even though the common use cases may not have such problems. In other words, implementing MI may not be worthwhile. – Ken Wayne VanderLinde Aug 06 '14 at 18:43
  • @KenWayneVanderLinde I understand that MI takes additional work to implement, but if it's already been implemented by someone else (as in the case of C++) then I can't see any reason why the GIMP folks would care. – weberc2 Aug 06 '14 at 18:51
  • @Rawler What's the problem with binding the C++ to C and then binding the other language to C? As I understand it, binding from C++ to C is relatively easy. – weberc2 Aug 06 '14 at 18:52
  • @weberc2 Replace C++ with "language of your choice" and all these same arguments can be made. But if we're going to make C bindings anyways, why bother? At the end, it boils down to a choice, not a technical restriction. – Ken Wayne VanderLinde Aug 06 '14 at 18:58
  • @KenWayneVanderLinde It's easier to write C bindings for C++ libs than for many other languages AFAICT. `At the end, it boils down to a choice, not a technical restriction` <- One hopes technical concerns are factored into decisions, but remember: we're talking about _why the choice may have been made_. Perhaps the decision to write the GObject system did derive from the points you outlined above, but I want to clearly highlight that those points are mostly misinformation. :S – weberc2 Aug 06 '14 at 19:23
  • @kert to be pedantic, you mean C++ has various ABIs but not _yet_ a _standardised_ ABI that would guarantee interoptability between compilers on a single architecture - and I say **yet** because they are working on it, e.g. this by Sutter: https://isocpp.org/files/papers/n4028.pdf – underscore_d Feb 12 '16 at 09:20
  • 1
    @underscore_d yes, i've been tracking that too, but its a long road before there is a critical mass of compilers, OSes and basic libraries onboard. Once there is an actual OS kernel built on top of extern "abi" ( and its not called Symbian ;) ) victory can be claimed. – kert Feb 12 '16 at 20:51
15

GObjects is intended to be language independent. It has dynamic typing, and you should it compare with a run-time system like COM, .NET or CORBA, rather than with specific languages. If you go into languages, then the features are more at the Objective-C than the C++ side.

Matthias
  • 8,018
  • 2
  • 27
  • 53
13

The GObject type system does things that you can't do in C++. For one thing, it allows creation of new classes at runtime, and does this in a way that is language-independent - you can define a new class in Python at runtime, then manipulate instances of that class within a function written in C, which need not even be aware that Python was ever involved.

gcbenison
  • 11,723
  • 4
  • 44
  • 82
  • 6
    Pedantic, perhaps, but it can be done in C++. You mean that it isn't built-in to C++, with regards to run-time class creation. – Sion Sheevok Mar 17 '12 at 05:55
  • I don't think I've ever needed to dynamically create a class. Genuinely curious--are there any real use cases for this? If so, what are some examples? – weberc2 Aug 06 '14 at 18:38
  • @weberc2 I've used run-time class creation in library bindings. You can walk a library API at runtime and make a GObject class (and therefore a GObject API) for each main feature. – jcupitt Oct 17 '14 at 13:51
  • 1
    @user894763 which enables you to do what, exactly? – weberc2 Oct 17 '14 at 14:53
  • @weberc2 Use that library from any language with a GObject binding. – jcupitt Oct 18 '14 at 15:31
  • 1
    @user894763 Perhaps I'm still misunderstanding, but that seems a bit circular. My question was effectively, "Why would you need to dynamically create a class?" and your answer was effectively, "To dynamically create classes". Can you elaborate a little more on *why* someone might want to dynamically create classes? Why is this a useful feature? – weberc2 Oct 19 '14 at 13:02
  • 1
    Sorry I'm not being very clear. Suppose you have libfoo, a library not based on GObject, and you'd like to use it from a language like JavaScript, which has a mature GObject interface. One way to do this is to write a tiny bit of C to introspect libfoo and (at runtime) generate a set of GObject classes, one for each feature you'd like to use. Now you can call libfoo from JS. The advantage here would be that the binding is made at runtime and so will automatically update as features are added to libfoo. Of course there are many ways to make library bindings, but this can be useful in some cases – jcupitt Oct 20 '14 at 13:45
  • @user894763 Nice idea, but it sounds easier said than done ;-) Can you provide some examples of where this has practically been achieved? – underscore_d Feb 12 '16 at 09:21
  • 1
    @underscore_d, here's an example from one of my projects. I maintain a GObject-based image processing library: https://github.com/jcupitt/libvips You can use it from at least Ruby, Python and JavaScript via those languages GObject bindings. The previous version of vips was not GObject-based, so you can't use operations from the old API ... except there's a thing to walk the old introspection system and generate GObject classes, so you can! https://github.com/jcupitt/libvips/blob/be4ffa6d8ac966f5498e1008561114f3996ad11c/libvips/deprecated/wrapvips7.c#L72 – jcupitt Feb 12 '16 at 09:46
  • @user894763 Cool, thanks! – underscore_d Feb 12 '16 at 10:21
5

From the wiki linked to in the question:

History (From Wikipedia)

GTK+ was originally designed and used in the GNU Image Manipulation Program (GIMP) as a replacement of the Motif toolkit; at some point Peter Mattis became disenchanted with Motif and began to write his own GUI toolkit called the GIMP toolkit and had successfully replaced Motif by the 0.60 release of GIMP.[3] Finally GTK was re-written to be object oriented and was renamed GTK+. This was first used in the 0.99 release of GIMP.

This should tell you that object-oriented paradigm was not a paramount criterion for the choice of language for GTK (which is different from GTK+) and that feature was added much later.

Community
  • 1
  • 1
user1055604
  • 1,624
  • 11
  • 28
  • I still don't understand why anyone would inflict that kind of pain upon themselves. C++ isn't great, but it sucks infinitely less than GObject. :( – weberc2 Apr 30 '15 at 19:13
  • 2
    ...What made you think this was an answer? The question is **why** it was re-written **in C**, instead of C++ or some other natively OOP language. Just telling us that "it was re-written" is a total tautology. I guess we're meant to _infer_ that it wasn't a total rewrite and/or the core team had preferences for C - for reasons supposed in better answers. – underscore_d Feb 12 '16 at 09:26
  • 2
    This is a good answer. The GIMP is a C project. GTK (and GTK+) was initially written to be a GUI toolkit for The GIMP, so C was a natural choice for a C project's library. GObject was extracted from GTK+, and retained the C heritage. It's still C because the entire heritage was C, and it was originally extracted from a C library for a C program. At no point in the history did another language make much sense for this purpose. If it was written initially from the ground up to be an object system, it might have been different, but its history wasn't that kind of project. – Taywee Jun 07 '16 at 18:10
  • 1
    It's called GIMP, not The GIMP. The Gimp is a fictional character in a Quentin Tarantino movie. – Richard Barber May 09 '20 at 22:36