doc/concepts.tex: Clearly distinguish between types and classes.

[sod] / doc / structures.tex

diff --git a/doc/structures.tex b/doc/structures.tex
index b2835fe..37ca9e3 100644 (file)
--- a/doc/structures.tex
+++ b/doc/structures.tex
@@ -410,7 +410,7 @@ and this is followed by corresponding members
 \end{prog}
 for each of $C$'s superclasses $A$ in the same chain in some (unimportant)
 order.  The (somewhat obtuse) purpose of this union is to engage the `common
 \end{prog}
 for each of $C$'s superclasses $A$ in the same chain in some (unimportant)
 order.  The (somewhat obtuse) purpose of this union is to engage the `common

-initial sequence' rule of \cite[6.5.2.3]{FIXME:C99}.
+initial sequence' rule of \cite[6.5.2.3]{ISO:1990:IIP,ANSI:1999:AII}.

 
 \subsubsection{The ichain structure}
 The @|ichain| structure contains (in order), a pointer
 
 \subsubsection{The ichain structure}
 The @|ichain| structure contains (in order), a pointer


@@ -450,9 +450,9 @@ superclass in the same chain, and each slot must be stored in exactly one
 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
 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.
 
 A vtable for a class $C$ with chain head $H$ has the following general
 structure.


@@ -489,9 +489,9 @@ first.
 
 This is mostly an irrelevant detail, whose purpose is to defend against
 malicious compilers: pointers are always to one of the inner @|vt|
 
 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}
 \begin{prog}
   const union $A$__vtu_$i$ $C$__vtable_$i$;
 \end{prog}


@@ -530,14 +530,14 @@ traversal.
 
 \item Let $N$ be the metaclass of $A$.  Examine the superclass chains of $N$
   in order of decreasing specificity of their most-specific classes.  Let $J$
 
 \item Let $N$ be the metaclass of $A$.  Examine the superclass chains of $N$
   in order of decreasing specificity of their most-specific classes.  Let $J$

-  be the chain head of such a chain, and let $Q$ be the most specific
-  superclass of $M$ in the same chain as $J$.  Then, if there is currently no
-  class pointer of type $Q$, then add a member
+  be the chain head of such a chain.  If there is currently no class pointer
+  for the chain headed by $J$, then add a member

   \begin{prog}
     const $Q$ *_cls_$j$;
   \end{prog}
   to the vtable pointing to the appropriate @|islots| structure within $M$'s
   \begin{prog}
     const $Q$ *_cls_$j$;
   \end{prog}
   to the vtable pointing to the appropriate @|islots| structure within $M$'s

-  class object.
+  class object, where $Q$ is the most specific superclass of $M$ in the same
+  chain as $J$.

 
 \item Examine the superclass chains of $A$ in order of decreasing specificity
   of their most-specific classes.  Let $I$ be the chain head of such a chain.
 
 \item Examine the superclass chains of $A$ in order of decreasing specificity
   of their most-specific classes.  Let $I$ be the chain head of such a chain.


@@ -637,13 +637,22 @@ defined for the sake of completeness.
 Finally, the class object is defined as
 \begin{prog}
   extern const struct $R$__ilayout $C$__classobj;               \\
 Finally, the class object is defined as
 \begin{prog}
   extern const struct $R$__ilayout $C$__classobj;               \\

-  \#define $C$__class (\&$C$__classobj.$j$.$r$)
+  \#define $C$__class (\&$C$__classobj.$j$.$r$)                 \\
+  \#define $C$__cls_$k$ (\&$C$__classobj.$k$.$n$)               \\
+  \quad$\vdots$

 \end{prog}
 The exported symbol @|$C$__classobj| contains the entire class instance.
 This is usually rather unwieldy.  The macro @|$C$__class| is usable as a
 pointer of type @|const $R$~*|, where $R$ is the root metaclass of $C$, i.e.,
 the metaclass of the least specific superclass of $C$; usually this is
 \end{prog}
 The exported symbol @|$C$__classobj| contains the entire class instance.
 This is usually rather unwieldy.  The macro @|$C$__class| is usable as a
 pointer of type @|const $R$~*|, where $R$ is the root metaclass of $C$, i.e.,
 the metaclass of the least specific superclass of $C$; usually this is

-@|const SodClass~*|.
+@|const SodClass~*|.  For each chain of $C$'s metaclass, a macro
+@|$C$__cls_$k$| is defined, usable as a pointer of type @|const $N$~*|, where
+$K$ and $N$ are the chain's head and tail classes (i.e., the least- and
+most-specific classes in the chain) respectively; this macro is
+\emph{omitted} if $N = R$, i.e., in the common case where $C$'s metaclass is
+precisely the root metaclass, since the existing @|$C$__class| macro is
+already sufficient.
+

 
 %%%----- That's all, folks --------------------------------------------------
 
 
 %%%----- That's all, folks --------------------------------------------------