GObject
GObject（GLib Object System）は、移植性の高いオブジェクトシステムと言語間の透過的相互運用性を提供するフリーなライブラリ（LGPL）である。GObjectはC言語で実装されており、他の言語ではバインディングによって利用可能となっている。
GLibとlibcにのみ依存しており、GNOMEの基礎として GTK+、Pango、Accessibility Toolkit、多くのGNOMEライブラリやアプリケーションなど広範囲に利用されている。GTK+ 2.0 以前は、GObject のコードは GTK+ の一部だった。ただし、当時は GObject とは呼ばれておらず、ベースクラスは codice_1 と呼ばれていた。
GTK+ 2.0 リリースの際に、オブジェクトシステムを汎用ユーティリティとすべく、別ライブラリとして分離した。その際にGUI関係でない codice_1 クラスの大部分は新たなベースクラスである codice_3 に移された。GTK+ 2.0 のリリースされた2002年3月11日以降、GOjbect は独立したライブラリとして存在し続け、現在ではGUI以外のCUIアプリケーションやサーバアプリケーションにも広く使われている。
GObject のマニュアル等はGLibとは別にあり、ライブラリファイルとしても別になっているが、ソースコードは GLib のソースツリー内にあって、GLib と共に配布されている。このため、GObject のバージョン番号は GLib のものを使っており、GLib パッケージの一部とされることが多い（例えば、DebianではGObjectを codice_4 パッケージファミリに入れている）。
GObjectフレームワークの基盤として、汎用の動的型システム GType がある。GTypeシステムは全オブジェクトの実行時記述を保持し、各種言語バインディングを実現するグルーコードからそれを使うことができる。型システムは任意の単一継承クラス階層を扱え、同時にクラスでないデータ型も扱える（不透明ポインタ、文字列、各種サイズの整数と浮動小数点数など）。
GType は登録されている型に属する値のコピー、代入、破棄の方法を知っている。整数などの型ではこれらは自明だが、複雑なオブジェクトには参照カウントがあるものもあれば、（一部だが）参照カウントのないものもある。型システムが参照カウントのあるオブジェクトを「コピー」するとき、一般に単に参照カウントをインクリメントするだけである。しかし、参照カウントのないオブジェクト（例えば文字列）のコピーでは、メモリを確保して実際にコピーを生成する。
この基本機能を使って codice_5 が実装されている。これは汎用コンテナ型であり、型システムが把握している任意の型の値を保持できる。このようなコンテナは、全てのネイティブ値をそのような型タグコンテナに格納する動的型付き言語とやりとりする際に特に便利である。
クラスと関連のない型を "non-classed" と称する。そのような型と何らかの root クラスに対応した全ての型を総称して「基本型」と呼び、それ以外の型を「派生型」と呼ぶ。これらは比較的閉じた体系であり、一般ユーザーが独自の基本型を生成することはないものと想定されているが、生成は可能であり、codice_3 クラスに基づかないクラス階層を独自に作ることもできる。
GLib 2.9.2では、"non-classed" の基本型は以下の通りである。
"classed" の基本型は以下の通りである。
型システムによって自動的にインスタンス化できる型を "instantiable" と称する。そのような型の重要な特徴は、インスタンスの先頭数バイトに必ずその型に対応したクラス構造（一種の仮想関数テーブル）へのポインタが格納されている点である。このため、instantiable な型は必ずクラスと対応している。逆に non-classed な型（整数や文字列）は instantiable ではない。また、classed な型はインタフェース型などを除いて instantiable である。
GObject の組み込みの基本型から派生する型は4種類に分けられる。
GObject のメッセージングシステムは、相補的な "closure" と "signal" から構成される。
GObject のクラスはクラス構造体とインスタンス構造体という少なくとも2つの構造体で実装される。
C言語の構造体には“public”、“protected”、“private”といったアクセス修飾がないので、インスタンス構造体にプライベートデータへのポインタ codice_44 がある。プライベート構造体は共通ヘッダファイルに宣言することはできるが、定義は個々の実装ファイルでのみ行われ、外部から見えないようにしている。プライベート構造体をGTypeに登録すると、自動的にオブジェクトシステムで確保される。プライベートデータが必要なとき常に codice_45 を使うようにすれば、codice_44 ポインタを構造体に含める必要はない。
GObjectフレームワークの欠点は、冗長性である。新たなクラスを生成するとき、型登録や各種マクロを多量にコーディングする必要があり、その多くは決まりきった形式である。GObject Builder や GOB2 はこの問題に対処するツールであり、Java風の構文からコードを生成できる。GOB2 で書かれたコードはコンパイル前にC言語のコードに展開される。他にもC#風の文法でコーディングできる Vala がある。
C言語とGObjectを使っているフリーソフトウェアプロジェクトとしては、GNOMEデスクトップ、GTK+ツールキット、GIMP画像編集プログラムなどがある。
GObjectを使ったアプリケーションはC言語で書かれていることが多いが、GObject 自体はC++、Java、Ruby、Python、.NET/Monoなどのオブジェクトシステムともうまくマッピングできる。従って、GObjectフレームワークを使ったライブラリに言語バインディングを作るのは比較的簡単である。
しかし、C言語でGObjectのコードを書くのは若干大変である。特に高級オブジェクト指向言語に慣れたプログラマにとっては苦痛かもしれない。例えば、ちょっとしたサブクラスを書くだけで数百行のコードを必要とする。とはいうものの、GObject を使うことでC言語でオブジェクト指向的なコーディングが可能となる。
一級オブジェクトは存在しないが（GTypeにはメタタイプがない）、GObjectアプリケーションは実行時にクラスやインタフェースのようなメタオブジェクトを生成でき、イントロスペクションもサポートできる。この機能は言語バインディング以外にGladeなどのGUI設計アプリケーションで使われ、GObjectクラスを提供する共有ライブラリをロードし、そのクラスの全プロパティの一覧を獲得し、型情報とドキュメンテーション文字列を完成させるといったことが可能となる。
GObject はC言語での完全なオブジェクトシステムであり、C言語から派生したC++やObjective-Cと同等のものと見ることもできる（ただし、C++ はオブジェクトシステム以外にも様々な機能がある）。C++ と GObject の明らかな違いは、GObject が多重継承をサポートしていない点である。
もう1つの重要な違いは、C++ や Objective-C が独立した言語であるのに対して、GObject は単なるライブラリであり、新たな構文やコンパイラ機能を追加しているわけではないという点である。例えば、GObjectベースのコードを書くとき、明示的な cast が頻繁に必要となる。従ってGObjectとC言語の組合せを通常のC言語とは別の言語と考えたとき、それはC++とは異なり、通常のC言語の厳密なスーパーセットとなっている。
C++コンパイラを対象とした標準ABIは存在しないので（例外としてWindowsではCOMがその役割を担っている）、あるC++コンパイラでコンパイルされたライブラリから、別のC++コンパイラでコンパイルされたライブラリを呼び出せないことがある。そのような互換性を必要とする場合、C++メソッドはC言語の関数としてエクスポートされる必要があり、C++のオブジェクトシステムが部分的に破綻する。原因の一部は、C++コンパイラがエクスポートするシンボルの一意性を保証するために、それぞれ独自に名前修飾しているためである。一方これとは対照的に、C言語にはオーバーロードも名前空間もないので、C言語ライブラリではエクスポートされるシンボルの一意性を保証するために明示的なプレフィックスを付けるのが一般的である。GObjectベースのライブラリはオブジェクト指向ではあるがC言語で書かれているので、コンパイラが何であっても明示的なシンボル名を使う。
おそらく最も意義のあるGObjectの特徴は Signal（他の言語ではイベントと呼ばれる）である。これは、GObject がGUIツールキット向けに開発されたために必要になった機能である。他のオブジェクト指向言語にも同様の機能はあるが、GObjectではオブジェクトシステムそのものに組み込まれている。このため、GObjectアプリケーションはSignalを多用する傾向があり、GObjectのコンポーネントは C++ や Java よりもカプセル化とコードの再利用という面で優れている。