C++ bungles this one badly, but we can do better.
\subsection{C language integration} \label{sec:concepts.classes.c}
\subsection{C language integration} \label{sec:concepts.classes.c}
+It is very important to distinguish compile-time C \emph{types} from Sod's
+run-time \emph{classes}: see \xref{sec:concepts.classes}.
+
For each class~$C$, the Sod translator defines a C type, the \emph{class
type}, with the same name. This is the usual type used when considering an
object as an instance of class~$C$. No entire object will normally have a
For each class~$C$, the Sod translator defines a C type, the \emph{class
type}, with the same name. This is the usual type used when considering an
object as an instance of class~$C$. No entire object will normally have a
chains. See \xref{sec:structures.layout} for the full details.} %
so access to instances is almost always via pointers.
chains. See \xref{sec:structures.layout} for the full details.} %
so access to instances is almost always via pointers.
+Usually, a value of type pointer-to-class-type of class~$C$ will point into
+an instance of class $C$. However, clever (or foolish) use of pointer
+conversions can invalidate this relationship.
+
\subsubsection{Access to slots}
The class type for a class~$C$ is actually a structure. It contains one
member for each class in $C$'s superclass chain, named with that class's
\subsubsection{Access to slots}
The class type for a class~$C$ is actually a structure. It contains one
member for each class in $C$'s superclass chain, named with that class's