GObject - Comparisons To Other Object Systems

Comparisons To Other Object Systems

Since GObject provides a mostly complete object system for C, it can be seen as an alternative to C-derived languages such as C++ and Objective-C. (Though both also offer many other features beyond just their respective object systems.) An easily observed difference between C++ and GObject is that GObject (like Java) does not support multiple inheritance.

GObject's use of GLib's g_malloc memory allocation function will cause the program to exit unconditionally upon memory exhaustion, unlike the C library's malloc, C++'s new, and other common memory allocators which allow a program to cope with or even fully recover from out-of-memory situations without simply crashing. 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.

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. For example, when writing GObject-based C code, it is frequently necessary to perform explicit upcasting. Hence, “C with GObject”, considered as a language separate from plain C, is a strict superset of plain C — unlike C++.

On platforms where there is no standard ABI that works across all C++ compilers (which is not usually the case, since either the Itanium ABI or the Microsoft ABI are usually followed), a library compiled with one C++ compiler is not always able to call a library compiled with a different one. If such compatibility is required, the C++ methods must be exported as plain C functions, partly defeating the purpose of the C++ object system. The problem occurs in part because different C++ compilers use different kinds of name mangling to ensure the uniqueness of all exported symbols. (This is necessary because, for example, two different classes may have identically named member functions, one function name may be overloaded multiple times, or identically named functions may appear in different namespaces, but in object code these overlaps are not allowed.) 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. 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.

Perhaps the most profound difference is GObject’s emphasis on signals (called events in other languages). This emphasis derives from the fact that GObject was specifically designed to meet the needs of a GUI toolkit. Whilst there are signal libraries for most object-oriented languages out there, in the case of GObject it is built into the object system. Because of this, a typical GObject application will tend to use signals to a much larger extent than a non-GObject application would, making GObject components much more encapsulated and reusable than the ones using plain C++ or Java. Note however that signals are available on almost all platforms, although sometimes an extra library is needed, such as Boost.Signals2 for C++.