mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2024-11-10 11:26:16 +01:00
Fix a typo reported by Laurent Lemaitre. Tweak the GType section on instiable objects and update the change list.
This commit is contained in:
parent
33129dca91
commit
75a9e23f18
@ -541,15 +541,23 @@ The class initialization process is entirely implemented in
|
||||
|
||||
<para>
|
||||
As many readers have now understood it, the base initialization/finalization process is
|
||||
very similar to the C++ Constructor/Destructor paradigm. However, it is very different
|
||||
in that, in C++, class constructors are automatically edited at compile
|
||||
time by the compiler to ensure that classes are correctly initialized before
|
||||
running the user-provided constructor code itself. With GObject, users must provide both
|
||||
the class and instance initialization functions.
|
||||
Similarly, GTypes have no instance destruction mechanism. It is
|
||||
very similar to the C++ Constructor/Destructor paradigm. The practical details are quite different
|
||||
though and it is important not to get confused by the superficial similarities. Typically, what
|
||||
most users have grown to know as a C++ constructor (that is, a list of
|
||||
object methods invoked on the object instance once for each type of the inheritance hierachy) does
|
||||
not exist in GType and must be built on top of the facilities offered by GType. Similarly,
|
||||
GTypes have no instance destruction mechanism. It is
|
||||
the user's responsibility to implement correct destruction semantics on top
|
||||
of the existing GType code. (this is what GObject does. See
|
||||
<xref linkend="chapter-gobject"></xref>)
|
||||
<xref linkend="chapter-gobject"/>)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For example, if the object B which derives from A is instantiated, GType will only invoke the
|
||||
instance_init callback of object B while a C++ runtime will invoke the constructor of the object
|
||||
type A first and then of the object type B. Furthermore, the C++ code equivalent to the base_init
|
||||
and class_init callbacks of GType is usually not needed because C++ cannot really create object
|
||||
types at runtime.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -133,7 +133,7 @@ all the objects manipulated by the programmer. This so-called <emphasis>dynamic
|
||||
</footnote>
|
||||
|
||||
library is then
|
||||
used by special generic glue code to automatically convert function parameters and function caling conventions
|
||||
used by special generic glue code to automatically convert function parameters and function calling conventions
|
||||
between different runtime domains.</para></listitem>
|
||||
</itemizedlist>
|
||||
The greatest advantage of the solution implemented by GType is that the glue code sitting at the runtime domain
|
||||
|
Loading…
Reference in New Issue
Block a user