Gustavo Sverzut Barbieri

Yes, you read it right: GLib is a technical disaster. After some time working with it, both using, building upon and hacking its internals, you can see the mess.

One thing that really piss me off is people that, instead of solving problems, create more problems that they call a “work-around”. GLib just do that: compiler-aided OO languages were badly supported in GCC? Let’s fix GCC? No, let’s create OO atop C, using a lot of pre-processor, make things cumbersome, error-prone, … POSIX and its GNU/LibC implementation lacks features? Let’s create a whole new string, list and hash implementation! Oh, and do not forget that missing printf(), make it g_print()!

I’m not a C++ enthusiast, but I do think it or ObjectiveC or any other compiler-aided Object Oriented language would help. Anyone that already implemented GObject subclasses know what I’m talking about. The very first thing you’ll notice is that you have to copy and paste too much code, but still have to change little bits here and there, making the process error-prone. Then you have the pre-processor macros and if you already worked with them or read Linux kernel position on it, you know it’s a mess and should be avoided. And how about a dynamic type system using C? Yes, GLib does have that, making things slower, bigger and impossible to compiler to optimize virtual-tables and dispatchers! And back to GCC, it’s now good enough and improving support for OO languages, but GLib/GObject will win nothing, GCC still handle it as regular procedural code.

Insanity doesn’t stop there, some Software Engineer Guru wanted to have “private” fields and yes, they also did it, even worse: they seem to incentive that! Any experienced hacker must know that this is just bullshit… and when you’re dealing with barebone C, where you have direct access to memory, you just think “they’re playing jokes”. Let’s suppose you could protect memory regions, why would you protect it? Against developers? Why? This idea must came from a non-programmer, because any programmer should know what to do and this just make debugging and testing more difficult. But let’s face it: C doesn’t offer any way to protect memory regions, so all you have to do is to have pointer to an area and use it… but they like the ClassNamePrivate, that just make things bigger, slower and painful to debug. If Operating System Kernels, that deals with critical data, don’t do any fancy stuff to “protect” it, why GLib guys do?

Still looking how BSDs and Linux relates to GLib and GObject, you can see that the kernels have saner implementation of linked lists, trees and hash tables. They also have clever Object Oriented code (vfs and others). Weird enough, hacking Linux or BSDs kernels are much easier when you compare easy-of-use and consistency of APIs.

How about namespaces and method resolution? Why would I use a language that supports that? It’s so cool to use gtk_label_set_text() or filling your mind with Object Hierarchies! Of course it’s gtk_misc_get_padding() if I’m dealing with a GtkLabel. When using these functions you may also opt to use casts and make it even more error prone or to use those GTK_LABEL()-like macros, that do function calls and some branches.

Just to make it clear: I know other languages and libraries have problems too. Qt is another good example on how-to-not-fix-the-proper-problem: stl is broken, let’s re-implement it! Why use namespaces, it’s just one letter! Let’s require user to pre-process their code (moc). However any of these are excuse, GLib has is a technical disaster because it tries to solve the wrong problem.

Trackback This Post | Subscribe to the comments through RSS Feed