Editing GObject (section)

==Comparisons to other object systems==
{{Original research|section|date=December 2011}}
{{Unreferenced section|date=November 2018}}

Since GObject provides a mostly complete object system for C{{citation needed|date=November 2018}}, 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]].<ref>{{Cite web|url=https://stackoverflow.com/questions/9747468/why-was-the-gobject-system-created/9747627|title=c++ - Why Was the GObject System Created?|website=Stack Overflow|access-date=2019-11-16}}</ref>

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 (C++)|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.<ref>{{Cite web|url=https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html#g-malloc|title=Memory Allocation: GLib Reference Manual|website=developer.gnome.org|access-date=2019-11-16}}</ref> 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. The g_try_new() can be used when a memory allocation is more likely to fail (for a large object for example), but this cannot grant that the allocation will not fail elsewhere in the code.<ref>{{Cite web|url=https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html#g-try-new|title=Memory Allocation: GLib Reference Manual|website=developer.gnome.org|access-date=2019-11-17}}</ref>

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 [[cast (computer science)|upcasting]].{{citation needed|date=November 2018}} Hence, “C with GObject”, also called "glib-flavored C", considered as a language separate from plain C, is a strict superset of plain C — like Objective C, but unlike C++.

On platforms where there is no standard [[Application binary interface|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.{{citation needed|date=November 2018}} 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|date=November 2018}} 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 [[method overloading|overloaded]] multiple times, or identically named functions may appear in different [[namespaces]], but in [[object code]] these overlaps are not allowed.){{citation needed|date=November 2018}} 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|date=November 2018}} 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 [[signal programming|signal]]s (called [[event-driven programming|event]]s in other languages).{{citation needed|date=November 2018}} 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 [[component-based software engineering|component]]s much more [[information hiding|encapsulated]] and reusable than the ones using plain C++ or Java.{{citation needed|date=November 2018}}{{According to whom|date=November 2018}} 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++. Of course, other implementations of signals are available on almost all platforms, although sometimes an extra library is needed, such as Boost.Signals2 for C++.

{{See also|IBM System Object Model#Comparison of support for compiled class libraries|l1=Comparison with COM, Objective-C, SOM, Windows Runtime, XPCOM}}