Instance chains contain slots and vtable pointers, as described below. All
instances have the basic structure of a @|struct sod_instance|.
-\begin{describe}[struct sod_instance]{type}
+\begin{describe}{type}[struct sod_instance]
{struct sod_instance \{ \\ \ind
const struct sod_vtable *_vt; \-\\
\};}
\end{description}
\end{describe}
-\begin{describe}[struct sod_vtable]{type}
+\begin{describe}{type}[struct sod_vtable]
{struct sod_vtable \{ \\ \ind
const SodClass *_class; \\
size_t _base; \-\\
\label{fig:structures.root.sodobject}
\end{figure}
-\begin{describe}[SodObject]{cls}
+\begin{describe}{cls}[SodObject]
{[nick = obj, metaclass = SodClass,
lisp_metaclass = sod_class] \\
class SodObject \{ \\ \ind
The following messages are defined.
- \begin{describe}[obj.init]{msg}{void init(?);}
+ \begin{describe}{msg}[obj.init]{void init(?);}
Initialize a newly allocated instance.
This message uses a custom method combination which works like the
\xref{sec:concepts.lifecycle.birth}.
\end{describe}
- \begin{describe}[obj.teardown]{msg}{int teardown();}
+ \begin{describe}{msg}[obj.teardown]{int teardown();}
Teardown an instance which is no longer required.
The message returns an integer flag. A zero value means that the
\subsection{The SodClass class} \label{sec:structures.root.sodclass}
-\begin{describe}[SodClass]{cls}
+\begin{describe}{cls}[SodClass]
{[nick = cls, link = SodObject] \\
class SodClass: SodObject \{ \\ \ind
const char *name; \\
\end{description}
\end{describe}
-\begin{describe}[struct sod_chain]{type}
+\begin{describe}{type}[struct sod_chain]
{struct sod_chain \{ \\ \ind
size_t n_classes; \\
const SodClass *const *classes; \\
place. The layout of vtables doesn't have this second requirement: it
doesn't matter that there are multiple method entry pointers for the same
effective method as long as they all work correctly. Indeed, it's essential
-that they do, because each chain's method entry function will need to apply a
-different offset to the receiver pointer before invoking the effective
-method.
+that there are multiple entry pointers, because each chain's method entry
+function will need to apply a different offset to the receiver pointer before
+invoking the effective method.
A vtable for a class $C$ with chain head $H$ has the following general
structure.
This is mostly an irrelevant detail, whose purpose is to defend against
malicious compilers: pointers are always to one of the inner @|vt|
-structures. It's important only because it's the outer @|vtu| union which is
-exported by name. Specifically, for each chain of $C$'s superclasses there is
-an external object
+structures. It's important only because it's the outer @|vtu| union which is
+exported by name. Specifically, for each chain of $C$'s superclasses there
+is an external object
\begin{prog}
const union $A$__vtu_$i$ $C$__vtable_$i$;
\end{prog}
~mdw / sod / blobdiff