A type, as manipulated by the GLib type system, is much more generic than what
is usually understood as an Object type. It is best explained by looking at the
structure and the functions used to register new types in the type system.

Fundamental types are top-level types which do not derive from any other type
while other non-fundamental types derive from other types.
Upon initialization by g_type_init, the type system not
only initializes its internal data structures but it also registers a number of core
types: some of these are fundamental types. Others are types derived from these
fundamental types.

Copy functions

The major common point between all GLib types (fundamental and
non-fundamental, classed and non-classed, instantiable and non-instantiable) is that
they can all be manipulated through a single API to copy/assign them.

The GValue structure is used as an abstract container for all of these
types. Its simplistic API (defined in gobject/gvalue.h) can be
used to invoke the value_table functions registered
during type registration: for example g_value_copy copies the
content of a GValue to another GValue. This is similar
to a C++ assignment which invokes the C++ copy operator to modify the default
bit-by-bit copy semantics of C++/C structures/classes.

The following code shows how you can copy around a 64 bit integer, as well as a GObject
instance pointer (sample code for this is located in the source tarball for this document in
sample/gtype/test.c):

The important point about the above code is that the exact semantics of the copy calls
is undefined since they depend on the implementation of the copy function. Certain
copy functions might decide to allocate a new chunk of memory and then to copy the
data from the source to the destination. Others might want to simply increment
the reference count of the instance and copy the reference to the new GValue.

The value_table used to specify these assignment functions is defined in
gtype.h and is thoroughly described in the
API documentation provided with GObject (for once ;-) which is why we will
not detail its exact semantics.

Interestingly, it is also very unlikely
you will ever need to specify a value_table during type registration
because these value_tables are inherited from the parent types for
non-fundamental types which means that unless you want to write a
fundamental type (not a great idea!), you will not need to provide
a new value_table since you will inherit the value_table structure
from your parent type.

[2]
Please note that there exists another registration function: the
g_type_register_dynamic. We will not discuss this
function here since its use is very similar to the _static
version.