
Klib: A standalone and lightweight glib - luu
https://github.com/attractivechaos/klib
======
awalton
This is really not a "standalone and lightweight glib", this is a generic data
structure library in C, and it's quite blatantly obvious they're designed for
different purposes.

glib is a platform and portability library that evolved away from gtk+, with
the goal being to make event driven programming simpler, both for system
daemons and Gtk+ applications. Most of glib's data structures are highly
_unoptimized_ simply because they don't need to run in critical paths of
whatever applications they're used in; optimizing would be mostly premature
(with some caveats; GSequence was added because of the need for a higher
performance list-like container , GHashTable got a lot of love a few years ago
because it turned out to be awful, etc). glib is ABI stable(-ish).

klib is written for doing data analysis and serialization in C, with two
releases in four years and no stability claims.

The two can co-exist quite nicely - I can easily see a glib application using
klib data structures along critical paths.

~~~
stormbrew
I'm surprised the title hasn't been changed. The actual website says "generic
lib" and at no point does it draw a direct comparison with glib. Usually these
things are changed much faster.

------
comex
If anyone's interested, here is a blog post I wrote a while back about a
subtle pitfall I encountered while using klib:

[http://blog.qoid.us/2014/04/10/klib.html](http://blog.qoid.us/2014/04/10/klib.html)

(Since then, after a few rewrites of similar generic containers using various
implementation techniques, I've settled on a style that minimizes the use of
macros in favor of inline functions [generated from an initial declaring
macro], adding verbosity but making the whole thing much easier to get right.)

~~~
bnolsen
his macros are truly evil. i wish he would have stayed with nicer c++ stuffs
ut on compiler challenged platforms...

------
slimsag
Is making so much use of macros for code generation really suggested practice
in C? It seems like it would be difficult to debug.

~~~
doomrobo
I think that macros are the only real option if you want to have an interface
for multiple types and still have some semblance of type-safety. The only
alternative I can think of is writing code that takes void* everywhere.

~~~
tbirdz
There is also the approach used for linked lists in the Linux Kernel:
[http://kernelnewbies.org/FAQ/LinkedLists](http://kernelnewbies.org/FAQ/LinkedLists)

------
jevinskie
All I have to say is that uthash and company was a lifesaver in my must-be-
written-in-C compiler course. It really, really simplified things. Of course
it can't just be bolted on, you need to write your code with some crazy
macros.

[http://troydhanson.github.io/uthash/](http://troydhanson.github.io/uthash/)

------
zhanxw
Does anyone know why it's called klib? I don't know about the prefix "k", but
guess it's borrowed a lot of kernel codes?

------
faragon
Nice library, and beautiful implementation.

