mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2025-02-04 18:26:19 +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>
|
<para>
|
||||||
As many readers have now understood it, the base initialization/finalization process is
|
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
|
very similar to the C++ Constructor/Destructor paradigm. The practical details are quite different
|
||||||
in that, in C++, class constructors are automatically edited at compile
|
though and it is important not to get confused by the superficial similarities. Typically, what
|
||||||
time by the compiler to ensure that classes are correctly initialized before
|
most users have grown to know as a C++ constructor (that is, a list of
|
||||||
running the user-provided constructor code itself. With GObject, users must provide both
|
object methods invoked on the object instance once for each type of the inheritance hierachy) does
|
||||||
the class and instance initialization functions.
|
not exist in GType and must be built on top of the facilities offered by GType. Similarly,
|
||||||
Similarly, GTypes have no instance destruction mechanism. It is
|
GTypes have no instance destruction mechanism. It is
|
||||||
the user's responsibility to implement correct destruction semantics on top
|
the user's responsibility to implement correct destruction semantics on top
|
||||||
of the existing GType code. (this is what GObject does. See
|
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>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -133,7 +133,7 @@ all the objects manipulated by the programmer. This so-called <emphasis>dynamic
|
|||||||
</footnote>
|
</footnote>
|
||||||
|
|
||||||
library is then
|
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>
|
between different runtime domains.</para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
The greatest advantage of the solution implemented by GType is that the glue code sitting at the runtime domain
|
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