Тегін бағдарламалық кітапхана: GObject жүйесі

Free software library

The GLib Object System, or GObject, is a free software library providing a portable object system and transparent cross language interoperability. GObject is designed for use both directly in C programs to provide object oriented C based APIs and through bindings to other languages to provide transparent cross language interoperability, e. g. PyGObject.

Depending only on GLib and libc, GObject is a cornerstone of GNOME and is used throughout GTK, Pango, 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 — the common baseclass was called GtkObject.) 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 GtkObject class were moved up into GObject, 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 applications.

Though GObject has its own separate set of documentation 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 libglib2.0 package family).

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 singly inherited class structure, in addition to non classed types such as opaque pointers, strings, and variously sized integers and floating point numbers. 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 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 allocating memory. This basic functionality is used for implementing GValue, 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 type tagged containers.

The GObject messaging system consists of two complementary parts: closures and signals. Closures A GObject closure is a generalized version of a 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.

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 — 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 (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 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. One approach is to include a pointer to the private data — conventionally called priv — 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 priv pointer, if one is willing to use the incantation G TYPE INSTANCE GET PRIVATE every time the private data is needed. To address some of these complexities, several higher level languages exist that source to source compiles to GObject in C. The Vala programming language uses a C# style syntax and is pre processed into vanilla C code. The GObject Builder, or GOB2, offers a template syntax reminiscent of Java.

GObject introspection (abbreviated GIR) is a foreign function interface middleware layer between C libraries (using GObject) and language bindings, cf. List of language bindings for GTK.

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, Ruby, Python, Common Lisp, and NET/Mono. As a result, it is usually relatively painless to create language bindings 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 GObject) can require writing and/or copying large amounts of boilerplate code. However, using 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 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.

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. 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. 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”, 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 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. 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++.