GLib

GLib is a bundle of three (formerly five) low-level system libraries written in C and developed mainly by GNOME. GLib's code was separated from GTK, so it can be used by software other than GNOME and has been developed in parallel ever since. GLib provides advanced data structures, such as memory chunks, doubly and singly linked lists, hash tables, dynamic strings and string utilities, such as a lexical scanner, string chunks (groups of strings), dynamic arrays, balanced binary trees, N-ary trees, quarks (a two-way association of a string and a unique integer identifier), keyed data lists, relations, and tuples. Caches provide memory management. GLib implements functions that provide threads, thread programming and related facilities such as primitive variable access, mutexes, asynchronous queues, secure memory pools, message passing and logging, hook functions (callback registering) and timers. GLib also includes message passing facilities such as byte order conversion and I/O channels. Some other features of GLib include: standard macros warnings and assertions dynamic loading of modules The GLib package consisted of five libraries, but they were all merged into one library, since then named simply GLib, and are no longer sustained as standalone libraries. The original libraries were: GObject, an object system including the type system GType GLib GModule GThread GIO Of these, three continue to reside in distinct subdirectories of the source tree, and so can be thought of as discrete components: GLib, GObject, and GIO. These can be thought of as a software stack: GObject relies on GLib, and GIO provides higher-level functionality that uses both. GLib began as part of the GTK+ project, now named GTK. However, before releasing GTK+ version 2, the project's developers decided to separate code from GTK+ that was not for graphical user interfaces (GUIs), thus creating GLib as a separate software bundle. GLib was released as a separate library so other developers, those not using the GUI-related parts of GTK+, could use the non-GUI parts of the library without the overhead of depending on the full GUI library.