luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-02-13 14:05:05 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: Remove redundant header examples from GObject tutorial

Browse Source 
These are in the header boilerplate section, but are actually source
boilerplate which is covered in later sections.

https://bugzilla.gnome.org/show_bug.cgi?id=744060
This commit is contained in:
Philip Withnall 2015-02-18 17:58:32 +00:00
parent 88e011a7cf
commit 32956587f3
1 changed files with 4 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

73
docs/reference/gobject/tut_howto.xml
View File

@ -80,10 +80,10 @@
<para> <para>
The basic conventions for any header which exposes a GType are described The basic conventions for any header which exposes a GType are described
in <xref linkend="gtype-conventions"/>. Most GObject-based code also in <xref linkend="gtype-conventions"/>.
obeys one of of the following conventions: pick one and stick to it. </para>
<itemizedlist>
<listitem><para> <para>
If you want to declare a type named bar with prefix maman, name the type instance If you want to declare a type named bar with prefix maman, name the type instance
<function>MamanBar</function> and its class <function>MamanBarClass</function> <function>MamanBar</function> and its class <function>MamanBarClass</function>
(name is case-sensitive). It is customary to declare them with code similar to the (name is case-sensitive). It is customary to declare them with code similar to the
@ -140,71 +140,6 @@ GType maman_bar_get_type (void);
#endif /* __MAMAN_BAR_H__ */ #endif /* __MAMAN_BAR_H__ */
</programlisting></informalexample> </programlisting></informalexample>
</para></listitem>
<listitem><para>
Types that require per-instance private data should use the
G_DEFINE_TYPE_WITH_PRIVATE() macro, or use the G_ADD_PRIVATE()
macro with the G_DEFINE_TYPE_WITH_CODE() or the G_DEFINE_TYPE_EXTENDED()
macros. The private structure is then defined in the .c file,
and can be accessed using the <function>get_instance_private()</function>
function generated by the G_DEFINE_TYPE_* macros. It is automatically
zero-filled on creation, so it is unnecessary to explicitly
initialize pointer members to NULL.
<informalexample><programlisting>
struct _MamanBarPrivate
{
int hsize;
};
G_DEFINE_TYPE_WITH_PRIVATE (MamanBar, maman_bar, G_TYPE_OBJECT)
static void
maman_bar_class_init (MamanBarClass *klass)
{
}
static void
maman_bar_init (MamanBar *self)
{
/* maman_bar_get_instance_private() is generated by G_DEFINE_TYPE_WITH_PRIVATE()
* above, and it's local to the current compilation unit.
*/
MamanBarPrivate *priv = maman_bar_get_instance_private (self);
priv->hsize = 42;
}
</programlisting></informalexample>
</para></listitem>
<listitem><para>
Most GNOME libraries use a pointer inside the instance structure
for simpler access to the private data structure, as described by
Herb Sutter in his Pimpl article (see <ulink url="http://www.gotw.ca/gotw/024.htm">Compilation Firewalls</ulink>
and <ulink url="http://www.gotw.ca/gotw/028.htm">The Fast Pimpl Idiom</ulink>
for reference). If you opt to use this idiom, you can assign the
pointer inside the instance initialization function, e.g.:
<informalexample><programlisting>
G_DEFINE_TYPE_WITH_PRIVATE (MamanBar, maman_bar, G_TYPE_OBJECT)
struct _MamanBarPrivate
{
int hsize;
};
static void
maman_bar_class_init (MamanBarClass *klass)
{
}
static void
maman_bar_init (MamanBar *self)
{
self->priv = maman_bar_get_instance_private (self);
self->priv->hsize = 42;
}
</programlisting></informalexample>
</para></listitem>
</itemizedlist>
</para> </para>
<para> <para>