GObject

title: 历史.
content: GObject仅依赖于GLib和libc。它是GNOME的基石并且在GTK+,Pango,Accessibility Toolkit和大多数GNOME的高级库和应用程序中被广泛使用。在GTK+ 2.0之前,GObject代码是GTK+的一部分。(现在GObject这个名字已经不在GTK+中了──取代它的基本类型叫做codice_1。)  由于对象系统适用的范围更广,较有一般性,所以在GTK+2.0发布时,对象系统被分离了出来,改放到了另一个函数库。GtkObject在Gtk演进的过程里,大部分与GUI不相关的部分都移到了GObject里,造就了新的共享基础类型GObject的诞生。从2002年3月11日(也就是GTK+ 2.0发布的日子)开始,GObject就一直以一个分离的函数库的形式存在。GObject函数库现在被许多非GUI的程序,像命令行应用程序、服务器应用程序等,所使用。
title: 与GLib的关系.
content: 虽然GObject有属于它自己的文件 与独立的函式库,但源代码却是在Glib的源码树里,并且与GLib一起发行。因此,GObject使用与GLib一样的版本号码,而且一般Linux Distro的作法也是把GObject包在GLib里(举例来说,Debian把GObject放在libglib2.0套件家族里)。
title: 类型系统.
content: GObject框架的基层主要依靠泛型与动态型别,称作GType。GType系统保留所有物件的执行时期描述以让glue code能方便地与其他语言作连结。类型系统可以处理任何单一继承的类别架构以及非类别的型别,如不透明指标、字串跟各种长度的整数与浮点数。  类型系统知道如何复制、指派和释放属于任何已注册类型的值。这对像整数这种不是参考计数(reference-counted)的型别来说是很琐碎的事情,但是对于其他是参考计数的复杂物件来说,是必要的。当类型系统复制了一个参考计数的物件,它仅仅只是增加该物件的参考计数,对复制一个复杂、不是参考计数的物件时,则是以配置内存的方式建立副本。  这项基本的能力被实作在GValue,GValue是一个泛型容器的型别,里面可以用来保存注册在类型系统里的型别的值。这样的容器在与动态型别语言沟通时,特别地有用。
title: 基础类型.
content: 没有任何关联类别的类型被称作非类别的。这些型别相当于根类别,也就是基础类型,可以被其他类型继承。  在GLib 2.9.2 里,非类别的内建基础类型有:  类别内建的基础类型有:  可以被系统自动实体化的类型被称作可实体化(instantiable)。这些类型的一个重要特色就是实体的第一个字节永远包含一个指标,指向连结到该实体类型的类别结构(虚拟表格的表单)。为此,任何可被实体化的类型应该是类别。相对地,任何非类别类型(像整数或字串)必须是不可实体化。另外,大部分类别类型是可实体化的,但某些类型,像接口类型,就不是。
title: 衍生类型.
content: 从内建GObject基础类型衍生下来的,主要有四种类型:
title: 讯息系统.
content: GObject讯息系统由两个互补的部分所组成:closures与信号。
title: 类别实作.
content: 每个GObject类别必须包含至少两个结构:类别结构与实体结构。  C结构没有像"public", "protected"或"private"等的存取层级修饰,一般的方法是借着在实体结构里提供一个指向私有资料的指标,照惯例称作_priv。私有的结构可以宣告在公有的表头档案里,然后把实体的定义写在实作的档案中,这样作,对使用者来说,他并不知道私有资料是什么,但对于实作者来说,却可以很清楚的知道。如果私有结构也注册在GType里,那么物件系统将会自动帮它配置空间。  GObject框架最主要的不利点在于太过于冗长。像是手动定义的类型转换宏和难解的型别注册咒语等的大量模板代码都是建立新类别所必要的。GObject Builder或GOB2这些工具试图以提供样板语法来解决这个问题。以GOB2写的代码必须事先处理过才能编译。另外,Vala可以将c# 的语法转换成C,并编译出独立的二进制档。
title: 用途.
content: C与GObject的组合被使用在许多成功的自由软件专案上,像是GNOME桌面、GTK与GIMP影像处理软件。  尽管许多的GObject应用程序完全以C来撰写,但GObject系统可以很好地对应到许多语言,像C++、Java、Ruby、Python和.NET/Mono等的原生物件系统。所以在为已经使用GObject框架写好的函式库建立语言系结时,通常比较不会那么痛苦。  以C来撰写GObject代码时,却是相对痛苦。学习曲线十分陡峭,有高阶物件导向语言经验的开发者可能会发现以C撰写GObject代码相当的乏味。举例来说,要继承一个类别(即使是继承GObject)可能就需要撰写和(或)复制上百行的代码。虽然如此,不可否认地,GObject可以为C的代码提供物件导向的功能。  GObject应用程序在执行时期为类别和接口所建立的元物件提供了互相操作的良好支援。可互相操作的能力被使用在语言系结上,还有使用者接口设计应用程序(如Glade)上。Glade允许加载提供放了Widget(元件,衍生自GObject)的函式库,并且取得类别的属性列表、类型资讯以及文件字串。
title: 与其他物件系统比较.
content: GObject为C提供了近乎完整的物件系统,所以使用C语言配合GObject,可以做为使用其他从C分支出去的语言,像C++和Objective-C,的替代方案。(不过C++和Objective-C其实各自有很多其他特色,而不是只有差在物件系统。) 最明显也最简单的不同,是GObject跟Java一样,不支援多重继承。  另一个重要的不同,GObject仅仅只是一个函式库,而C++和Objective-C的编译器还额外提供了新的语法或特性。  就目前的C++编译器来说,并没有标准的ABI可以在所有的C++编译器运行(除了Windows,Windows上有COM可以处理),以A这个C++编译器所编译出来的函式库,并不一定能被以B C++编译器所编译的程序呼叫。如果需要这样的相容性,C++的方法必须要输出为C的函式,这样就无法享受C++带来的好处了。这主要是因为不同的C++编译器使用了不同的名称特殊处理(Name mangling)以确保输出符号的独一性。(这是必要的,举例来说,不同的类别可能会有一样名称的成员函式、被覆载许多次的函式名称,或者出现在多个命名空间但同名的函式,但在输出为目的档时,这些代码都是独立的,如果名称都一样,会被视为同一份代码,因此需要对名称作特殊处理。)对照C来看,C不支援任何形式的覆载或名称特殊处理,C函式库的作者永远只能使用明确的前置名以确保输出名称的全域独一性。因此,以C撰写的GObject基底的函式库将不会有名称特殊处理的问题,也不会受到编译器的影响。  最后,"信号"(signal)可以说是更容易被发现的相异点了(在其他语言被称作事件)。这当然是因为GObject最早被设计用在GUI工具箱上。的确,许多物件导向语言都已经有现成的信号函式库,但GObject是被内建在物件系统里的。因此,GObject应用程序与其他非GObject应用程序比起来,会倾向于去使用信号来实作。这使得GObject 元件,相较于纯C++或Java写的元件,更易于封装,也容易被重复使用。不过该注意的是,在几乎所有的平台都可以使用信号,但有时其实需要额外的函式库支援,例如可用于C++的Boost.Signals2。

Summary: GLib对象系统,或者说GObject,是一个在LGPL下发布的自由软件库,它提供了一个轻便的对象系统并支持透明的多语言互通。GObject被设计为可以直接使用在C程序中,也封装至其他语言。

GObject: 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.