GObject
At the most basic level of the GObject framework lies a generic and dynamic type system called GType.
The GType system holds a runtime description of all objects allowing glue code to facilitate multiple language bindings.
The combination of C and GObject is used in many successful free software projects, such as the GNOME desktop, the GTK toolkit and the GIMP image manipulation program.
The library takes a good deal of time to learn, and programmers with experience in high-level object-oriented languages often find it somewhat tedious to work with GObject in C. For example, creating a subclass (even just a subclass of GObject) can require writing and/or copying large amounts of boilerplate code.
Although they are not really first-class objects (there are no actual metatypes in GType), metaobjects like classes and interfaces are created by GObject applications at runtime, and provide good support for introspection.
The introspective capabilities are used by language bindings and user interface design applications like Glade to allow doing things like loading a shared library that provides a GObject class—usually some kind of widget, in the case of Glade—and then obtain a list of all properties of the class, complete with type information and documentation strings.
[7] This tends to work against including GObject in software where resilience in the face of limited memory is important, or where very many or very large objects are commonly handled.
[8] Another important difference is that while C++ and Objective-C are separate languages, GObject is strictly a library and as such does not introduce any new syntax or compiler intelligence.
[citation needed] If such compatibility is required, the C++ methods must be exported as plain C functions, partly defeating the purpose of the C++ object system.
)[citation needed] In contrast, since C does not support any form of overloading or namespacing, authors of C libraries will typically use explicit prefixes to ensure the global uniqueness of their exported names.
[citation needed] Hence, despite being object-oriented, a GObject-based library written in C will always use the same external symbol names regardless of which compiler is used.
Whilst there are signal libraries for most object-oriented languages out there, in the case of GObject it is built into the object system.
If using glibmm/gtkmm, the official C++ wrappers to Glib/GTK respectively, the sibling project libsigc++ allows easy use of underlying GObject signals using standard C++.
