Another problem is that there is no type checking in the containers. So you have to cast everything to/from void pointers, even for basic structures like lists and arrays. This makes it easy to introduce tricky bugs.
The BSDs basically solved this problem decades ago: <sys/queue.h> and <sys/tree.h> provide type-safe core data structures sufficient for most C application needs. The amount of wheel reinvention and dependency complexity outside the BSD universe blows my mind. (Though, FreeBSD projects do have a greater tendency to complicate things, perhaps owing to the stronger corporate-induced feature chasing.)
The only real universal sore spot IME has been arrays and vectors. But nobody seems to pitch glib as a way to get a fast and ergonomic FIFO buffer. There are many other areas without simple, go-to solutions, but then that's the nature of C programming. Most of the C programmers I interact with are multi-language programmers, as opposed to many C++, Java, etc engineers who lean toward single-language, monolithic approaches.
I can understand using glib for GUI applications, considering it's already a requirement for Gtk, and because of the OOP emphasis in GUI programming. But IMNSHO, in most other areas the right reasons for selecting C as your implementation language are mutually exclusive with the need for cookie-cutter, void-pointer heavy data structure implementations a la glib.
EDIT: Removed outdated discussion of systemd + glib.
In addition, using void pointers harms performance as this strategy often incurs additional heap allocations, hurts memory locality and prevents compiler optimization. Personally, I avoid glib like a plague.
Comments
Another problem is that there is no type checking in the containers. So you have to cast everything to/from void pointers, even for basic structures like lists and arrays. This makes it easy to introduce tricky bugs.
The BSDs basically solved this problem decades ago: <sys/queue.h> and <sys/tree.h> provide type-safe core data structures sufficient for most C application needs. The amount of wheel reinvention and dependency complexity outside the BSD universe blows my mind. (Though, FreeBSD projects do have a greater tendency to complicate things, perhaps owing to the stronger corporate-induced feature chasing.)
The only real universal sore spot IME has been arrays and vectors. But nobody seems to pitch glib as a way to get a fast and ergonomic FIFO buffer. There are many other areas without simple, go-to solutions, but then that's the nature of C programming. Most of the C programmers I interact with are multi-language programmers, as opposed to many C++, Java, etc engineers who lean toward single-language, monolithic approaches.
I can understand using glib for GUI applications, considering it's already a requirement for Gtk, and because of the OOP emphasis in GUI programming. But IMNSHO, in most other areas the right reasons for selecting C as your implementation language are mutually exclusive with the need for cookie-cutter, void-pointer heavy data structure implementations a la glib.
EDIT: Removed outdated discussion of systemd + glib.
In addition, using void pointers harms performance as this strategy often incurs additional heap allocations, hurts memory locality and prevents compiler optimization. Personally, I avoid glib like a plague.