View source for GObject

{{Short description|Free software library}}

{{More citations needed|date=September 2025}}
{{Infobox software
| name                   = GLib
| title                  = GObject
| logo                   = <!-- Image name is enough -->
| screenshot             = <!-- Image name is enough -->
| developer              = [[The GNOME Project]]
| released               = {{Start date and age|2002|03|11|df=yes}}<!--Date only-->
| discontinued           = 
| latest release version = 
| latest release date    = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} -->
| latest preview version = 
| latest preview date    = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} -->
| programming language   = [[C (programming language)|C]]
| operating system       = [[Cross-platform]]
| platform               = 
| size                   = 
| language               = [[Multilingual]]{{which|date=November 2014}}
| language count         = <!-- Number only -->
| language footnote      = 
| genre                  = [[Software library]]
| license                = [[GNU Lesser General Public License|GNU LGPL]]
| alexa                  = 
| website                = {{URL|https://developer.gnome.org/gobject/stable/}}<!--One link only-->
}}

The '''GLib Object System''', or '''GObject''', is a [[free software|free]] [[software library]] providing a portable [[object system]] and transparent cross-language interoperability. GObject is designed for use both directly in [[C (programming language)|C]] programs to provide object-oriented C-based APIs and through [[language binding|binding]]s to other languages to provide transparent cross-language interoperability, e.g. [[PyGObject]].

==History==
Depending only on [[GLib]] and [[libc]], GObject is a cornerstone of [[GNOME]] and is used throughout [[GTK]], [[Pango]], [[Accessibility Toolkit|ATK]], and most higher-level [[GNOME]] libraries like [[GStreamer]] and applications. Prior to GTK+ 2.0, code similar to GObject was part of the GTK codebase. (The name “GObject” was not yet in use &mdash; the common baseclass was called <code>GtkObject</code>.)

At the release of GTK+ 2.0, the object system was extracted into a separate library due to its general utility. In the process, most non-[[GUI]]-specific parts of the <code>GtkObject</code> class were moved up into <code>GObject</code>, the new common baseclass. Having existed as a separate library since March 11, 2002 (the release date of GTK+ 2.0), the GObject library is now used by many non-GUI programs such as [[command-line]] and [[Server (computing)|server]] applications.

==Relation to GLib==
Though GObject has its own separate set of documentation<ref>{{cite web|url=https://developer.gnome.org/gobject/stable/|title=GObject Reference Manual}}</ref> and is usually compiled into its own [[shared library]] file, the source code for GObject resides in the [[GLib]] source tree and is distributed along with GLib. For this reason, GObject uses the GLib version numbers and is typically packaged together with GLib (for example, [[Debian]] puts GObject in its <code>libglib2.0</code> package family).

==The type system==
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 type system can handle any [[single inheritance|singly inherited]] class structure, in addition to ''non-classed'' types such as [[opaque pointer]]s, [[string (computer science)|strings]], and variously sized [[integer]]s and [[floating point number]]s.

The type system knows how to copy, assign, and destroy values belonging to any of the registered types. This is trivial for types like integers, but many complex objects are [[reference counting|reference-counted]], while some are complex but not reference-counted. When the type system “copies” a reference-counted object, it will typically just increase its reference count, whereas when copying a complex, non-reference-counted object (such as a string), it will typically create an actual copy by [[memory allocation|allocating memory]].

This basic functionality is used for implementing <code>GValue</code>, a type of generic container that can hold values of any type known by the type system. Such containers are particularly useful when interacting with dynamically typed language environments in which all native values reside in such [[tagged union|type-tagged]] containers.

===Fundamental types===
Types that do not have any associated [[class (programming)|class]]es are called ''non-classed''. These types, together with all types that correspond to some form of root class, are known as ''fundamental types'': the types from which all other types are derived. These make up a relatively closed set, but although the average user is not expected to create their own fundamental types, the possibility does exist and has been exploited to create custom [[class hierarchy|class hierarchies]] &mdash; i.e., class hierarchies not based on the <code>GObject</code> class.

As of GLib 2.9.2,<ref>{{cite web|url=https://developer.gnome.org/gobject/stable|title=GObject Reference Manual - Stable}}</ref> the ''non-classed'' built-in fundamental types are:
* an [[empty type]], corresponding to C's <code>void</code> (<code>G_TYPE_NONE</code>);
* types corresponding to C's signed and unsigned <code>char</code>, <code>int</code>, <code>long</code>, and 64-bit integers (<code>G_TYPE_CHAR</code>, <code>G_TYPE_UCHAR</code>, <code>G_TYPE_INT</code>, <code>G_TYPE_UINT</code>, <code>G_TYPE_LONG</code>, <code>G_TYPE_ULONG</code>, <code>G_TYPE_INT64</code>, and <code>G_TYPE_UINT64</code>);
* a Boolean type (<code>G_TYPE_BOOLEAN</code>);
* an [[enumeration]] type and a “flags” type, both corresponding to C's <code>enum</code> type, but differing in that the latter is only used for [[bit field]]s (<code>G_TYPE_ENUM</code> and <code>G_TYPE_FLAGS</code>);
* types for single- and double-precision [[IEEE float]]s, corresponding to C's <code>float</code> and <code>double</code> (<code>G_TYPE_FLOAT</code> and <code>G_TYPE_DOUBLE</code>);
* a [[string type]], corresponding to C's <code>char *</code> (<code>G_TYPE_STRING</code>);
* an opaque [[pointer type]], corresponding to C's <code>void *</code> (<code>G_TYPE_POINTER</code>).

The ''classed'' built-in fundamental types are:
* a base class type for instances of <code>GObject</code>, the root of the standard class inheritance tree (<code>G_TYPE_OBJECT</code>)
* a base [[Interface (object-oriented programming)|interface]] type, analogous to the base class type but representing the root of the standard ''interface'' inheritance tree (<code>G_TYPE_INTERFACE</code>)
* a type for [[Boxed type|boxed]] structures, which are used to wrap simple value objects or foreign objects in reference-counted “boxes” (<code>G_TYPE_BOXED</code>)
* a type for “parameter specification objects,” which are used in GObject to describe [[metadata]] for object properties (<code>G_TYPE_PARAM</code>).

Types that can be instantiated automatically by the type system are called ''instantiable''. An important characteristic of these types is that the first bytes of any instance always contain a pointer to the ''class structure'' (a form of [[virtual table]]) associated to the type of the instance. For this reason, any instantiable type must be classed. Contrapositively, any non-classed type (such as ''integer'' or ''string'') must be non-instantiable. On the other hand, most classed types are instantiable, but some, such as interface types, are not.

===Derived types===
The types that are derived from the built-in GObject fundamental types fall
roughly into four categories:
; Enumerated types and “flags” types : In general, every enumerated type and every integer-based bit field type (i.e., every <code>enum</code> type) that one wishes to use in some way that is related to the object system &mdash; for example, as the type of an object property &mdash; should be registered with the type system. Typically, the initialization code that takes care of registering these types is generated by an automated tool called <code>glib-mkenums</code><ref>{{cite web|url=https://developer.gnome.org/gobject/stable/glib-mkenums.html|title=glib-mkenums, GObject Reference Manual}}</ref> and stored in a separate file.
; Boxed types : Some data structures that are too simple to be made full-fledged class types (with all the overhead incurred) may still need to be registered with the type system. For example, we might have a class to which we want to add a <code>background-color</code> property, whose values should be instances of a structure that looks like {{code|2=c|1=struct color { int r, g, b; } }}. To avoid having to subclass <code>GObject</code>, we can create a [[boxed type]] to represent this structure, and provide functions for copying and freeing. GObject ships with a handful of boxed types wrapping simple GLib data types. Another use for boxed types is as a way to wrap foreign objects in a tagged container that the type system can identify and will know how to copy and free.
; Opaque pointer types : Sometimes, for objects that need to be neither copied or reference-counted nor freed, even a boxed type would be overkill. While such objects can be used in GObject by simply treating them as opaque pointers (<code>G_TYPE_POINTER</code>), it is often a good idea to create a derived pointer type, documenting the fact that the pointers should reference a particular kind of object, even though nothing else is said about it.
; Class and interface types : Most types in a GObject application will be classes &mdash; in the normal object-oriented sense of the word &mdash; derived directly or indirectly from the root class, <code>GObject</code>. There are also interfaces, which, unlike classic [[Java (programming language)|Java]]-style [[interface (object-oriented programming)|interfaces]], can contain implemented methods. GObject interfaces can thus be described as [[mixin]]s.

==Messaging system==
The GObject messaging system consists of two complementary parts: ''closures'' and ''signals''.
; Closures : A GObject closure is a generalized version of a [[Callback (computer science)|callback]]. Support exists for closures written in C and C++, as well as arbitrary languages (when bindings are provided). This allows code written in (for example) Python and Java to be invoked via a GObject closure.
; Signals : Signals are the primary mechanism by which closures are invoked. Objects register signal listeners with the type system, specifying a mapping between a given signal and a given closure. Upon emission of a registered signal, that signal's closure is invoked. In GTK, all native GUI events (such as mouse motion and keyboard actions) can generate GObject signals for listeners to potentially act upon.

==Class implementation==
Each GObject class is implemented by at least two structures: the ''class structure'' and the ''instance structure''.
; The class structure : The class structure corresponds to the [[vtable]] of a C++ class. It must begin with the class structure of the superclass. Following that, it will hold a set of function pointers &mdash; one for each [[virtual method]] of the class. Class-specific variables can be used to emulate class members.
; The instance structure : The instance structure, which will exist in one copy per object instance, must begin with the instance structure of the [[superclass (computer science)|superclass]] (this ensures that all instances begin with a pointer to the class structure, since all fundamental instantiable types share this property). After the data belonging to the superclass, the structure can hold any instance-specific variables, corresponding to C++ member variables.

Defining a class in the GObject framework is complex, requiring large amounts of [[boilerplate (text)#Boilerplate code|boilerplate]] code, such as manual definitions of type casting macros and obscure type registration incantations. Also, since a C structure cannot have access modifiers like “public”, “protected”, or “private”, workarounds must be used to provide [[Encapsulation (computer programming)|encapsulation]]. One approach is to include a pointer to the private data &mdash; conventionally called <code>_priv</code> &mdash; in the instance structure. The ''private structure'' can be declared in the public header file, but defined only in the implementation file, with the effect that the private data is opaque to users, but transparent to the implementor. If the private structure is registered with GType, it will be automatically allocated by the object system. Indeed, it is not even necessary to include the <code>_priv</code> pointer, if one is willing to use the incantation <code>G_TYPE_INSTANCE_GET_PRIVATE</code> every time the private data is needed.

To address some of these complexities, several higher-level languages exist that [[source-to-source compiler|source-to-source compiles]] to GObject in C. The [[Vala (programming language)|Vala programming language]] uses a [[C Sharp (programming language)|C#]]-style syntax and is pre-processed into [[Vanilla (computing)|vanilla]] C code. The GObject Builder, or [https://www.jirka.org/gob.html GOB2], offers a template syntax reminiscent of [[Java (programming language)|Java]].

==GObject Introspection==
* [https://gi.readthedocs.io/en/latest/ GObject introspection] (abbreviated GIR<ref>{{cite web |title=Introspection, Summary |url=https://developer.gnome.org/documentation/guidelines/programming/introspection.html |website=Gnome Developer, Programming Guidelines - Specific How-Tos |access-date=9 August 2020}}</ref>) is a [[foreign function interface]] middleware layer between C libraries (using GObject) and language bindings, cf. [[List of language bindings for GTK]].

==Usage==
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.

Though many GObject applications are written entirely in C, the GObject system maps well into the native object systems of many other languages, like [[C++]], [[Java (programming language)|Java]], [[Ruby programming language|Ruby]], [[Python (programming language)|Python]], [[Common Lisp]], and [[.NET Framework|.NET]]/[[Mono (software)|Mono]]. As a result, it is usually relatively painless to create [[language binding]]s for well-written libraries that use the GObject framework.

Writing GObject code in C in the first place, however, is relatively verbose. 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 <code>GObject</code>) can require writing and/or copying large amounts of [[boilerplate code]].<ref>{{cite web|title=How to define and implement a new GObject|url=https://developer.gnome.org/gobject/stable/howto-gobject.html|work=gnome.org|access-date=27 July 2013}}</ref> However, using [[Vala (programming language)|Vala]], a language that is designed primarily to work with GObject and which converts to C, is likely to make working with GObject or writing GObject based libraries nicer.

Although they are not really [[first-class object]]s (there are no actual metatypes in GType), [[metaobject]]s like classes and interfaces are created by GObject applications at runtime, and provide good support for [[introspection (computer science)|introspection]]. The introspective capabilities are used by language bindings and user interface design applications like [[Glade Interface Designer|Glade]] to allow doing things like loading a [[shared library]] that provides a GObject class—usually some kind of [[Web widget|widget]], in the case of Glade—and then obtain a list of all properties of the class, complete with type information and documentation
strings.

==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 signals (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}}

==See also==
{{Portal|Free and open-source software}}
* [[Vala (programming language)|Vala]] — a GObject-based programming language with [[C_Sharp_(programming_language)|C#]]-like syntax. [[Source-to-source compiler]] to [[C (programming language)|C]].

==References==
{{Reflist}}

==External links==
* [https://developer.gnome.org/gobject/stable/ The GObject Reference Manual (and tutorial)]
* [https://web.archive.org/web/20170202012725/http://article.gmane.org/gmane.comp.gnome.gtk%2B.devel.general/6329 GObject Tutorial Aug 2004]
* [https://www.jirka.org/gob.html GOB2 &mdash; the GObject Builder]
* [https://wiki.gnome.org/Projects/Vala Vala Homepage]

{{GTK}}

<!-- Interlang -->

{{DEFAULTSORT:Gobject}}
[[Category:C (programming language) libraries]]
[[Category:Free computer libraries]]
[[Category:Free software programmed in C]]
[[Category:Freedesktop.org]]
[[Category:GNOME libraries]]
[[Category:GTK]]