The thing is, if you're writing anything other than a trivial example, using GTK+ requires using GObject/GType, and this means that you will be:
- doing RTTI in C
- constructing virtual call tables by hand
- writing constructors and destructors by hand (not just the easy bits either, but all the extra stuff C++ does for you, plus you have to handle the multi-phase construction and destruction GObject performs, which is vastly more complex than C++)
- you'll be forced to use construction properties which are not efficient
- writing all the type initialisation and registration code to register your classes with GType
- generating all the cast macros
- doing all the refcounting by hand
- you'll need to know more about C++ implementation details than most C++ programmers in order to understand and use it
This "works", don't get me wrong. But... the level of expertise and proficiency required to do this is beyond silly. It requires the user to replicate, by hand, in C, complex implementation details which would be automatically generated by the C++ compiler, like vtables and typeinfos and marshalling. And all the RTTI stuff. At this point, you really have to question whether the "benefits of C/GObject" are worth the cost:
- It's more complex than C++
- It's more fragile than C++
- It's more difficult to maintain and refactor than C++
- It's slower
- Type bugs are often not found by the compiler because you cast away the type information; this is worked around by runtime checks but even these can fail to work properly, and have a cost since they are done for every method call.
- Memory leaks are common because you're doing all the refcounting by hand
If you wanted to start a new project and had to make the choice between C++ (which is well understood by many) or GObject/GType (which is not, and for good reason because it's awful) there isn't really a choice here at all. I used to be a C zealot who went through the pain of using GObject for OO-C even for non-GTK stuff; but I was deluding myself. C is not the best tool for every job, and it's not good at OO even if it's "technically possible". It's not the best tool for the job, not by a long shot. I ported it all to C++ years back, and found bugs while doing so which hadn't been picked up while using GObject. That is to say, converting it to conventional C++ code improved its quality significantly, and the bugs that I fixed would would not have been found while I continued to use GObject--they were hidden. And once converted to C++, refactoring and adding new functionality became simple; it was a significant burden with C/GObject and it was too easy to introduce subtle bugs since the compiler won't pick up the bugs for you.
Now, the harsh reality is that vala, the language bindings etc. are all various attempts to paper over these unfortunate fundamental shortcomings, while failing to actually address them. Some of them get close, but ultimately it's still built on the same very poor foundations. And you always run into bugs in the bindings, so if you want to do stuff properly you still have to do it in C.
Imagine a commercial project where you need to pitch this to your management for a new project. It's unlikely that GTK+/GObject could be chosen over C++--it would be a risky and irrational choice to make in the face of its many serious shortcomings. (I have done this in the past, before Qt was fully free; we went with GTKmm and still ran into many problems. Lately when evaluating cross-platform toolkits for new projects, Qt and PyQt are at the top of the list and GTK+ isn't even on the list, I'm sad to say.) Hiring or training staff to work on it would be difficult as well; the pool of C++ programmers who already know or could easily pick up Qt is vastly greater than the small number of masochists willing inflict GObject upon themselves (as I once did). It's not like it's even well documented, it's an exercise in pain and frustration. In comparison, the Qt documentation is pretty good.
GTK+ is, and was, driven primarily by "C zealots" (as I once was) who are prepared to use C for everything, come what may. Unfortunately, the reality for the rest of the world is that this is an unsuitable foundation for serious projects. Using GObject requires sacrificing code quality, maintainability and performance, and for most that's not acceptable since it doesn't provide any benefit, other than avoiding C++. It's not benefiting the project themselves.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds