29

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.

Improve this question
4
  • 1
    @HansPassant the project could still have been extended with C++. As C++ is compatible with C. Commented Mar 17, 2012 at 5:34
  • 1
    @IntermediateHacker: For the most part, C programs can be treated as C++ programs. But this is not a strict relationship, since certain C notions (e.g. restrict) do not exist in C++. Commented Mar 17, 2012 at 5:55
  • 3
    C++ is not "exactly" C with "object orientation capabilities" Commented Mar 18, 2012 at 10:29
  • GTK was not re-written primarily for addition of object-oriented features... look at the answer with Wiki quote... Commented Apr 28, 2012 at 19:48

4 Answers 4

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

16 Comments

@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.
I believe #3 was particularly attractive. Bindings for C++ can be done, but the situation have always been slightly better for C.
@NicolBolas: Either answer the question or don't, but your snide comments aren't helping anyone.
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.
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).
|
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.

Improve this answer

Comments

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.

Improve this answer

9 Comments

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.
@user894763 which enables you to do what, exactly?
@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?
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
@underscore_d, here's an example from one of my projects. I maintain a GObject-based image processing library: 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! github.com/jcupitt/libvips/blob/…
|
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.

Improve this answer

4 Comments

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. :(
...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.
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.
It's called GIMP, not The GIMP. The Gimp is a fictional character in a Quentin Tarantino movie.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.