@<type>_n @<slot>_n; \-\\
\} $c$; \-\\
\} $c$; \\
- struct $H$__ichain_$h$ $h$; \\
+ struct $A$__ichain_$h$ $a$; \\
\quad$\vdots$ \-\\
\} $h$; \\
union $B$__ichainu_$i$ $i$; \\
In general, the vtables for the different chains will have \emph{different}
structures.
-The instance layout split neatly into disjoint chains. This is necessary
+The instance layout splits neatly into disjoint chains. This is necessary
because each @|ichain| must have as a prefix the @|ichain| for each
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
@<type>_n @<arg>_n? \+\\
@<type>_{n+1} @<kw>_{n+1} @[= @<dflt>_{n+1}@],
$\ldots$,
- @<type>_m @<kw>_m @[= @<dflt>_m@]);
+ @<type>_{n'} @<kw>_{n'} @[= @<dflt>_{n'}@]);
\end{prog}
two entry points are defined: the usual `main' entry point which accepts a
variable number of arguments, and a `valist' entry point which accepts an