\subsubsection{Slot initializers}
As well as defining slot names and types, a class can also associate an
\emph{initial value} with each slot defined by itself or one of its
-subclasses. A class $C$ provides an \emph{initialization function} (see
+subclasses. A class $C$ provides an \emph{initialization message} (see
\xref{sec:concepts.lifecycle.birth}, and \xref{sec:structures.root.sodclass})
-which sets the slots of a \emph{direct} instance of the class to the correct
-initial values. If several of $C$'s superclasses define initializers for the
-same slot then the initializer from the most specific such class is used. If
-none of $C$'s superclasses define an initializer for some slot then that slot
-will be left uninitialized.
+whose methods set the slots of a \emph{direct} instance of the class to the
+correct initial values. If several of $C$'s superclasses define initializers
+for the same slot then the initializer from the most specific such class is
+used. If none of $C$'s superclasses define an initializer for some slot then
+that slot will be left uninitialized.
The initializer for a slot with scalar type may be any C expression. The
initializer for a slot with aggregate type must contain only constant
stash them in a dynamically allocated private structure, and leave a pointer
to it in a slot. (This will also help preserve binary compatibility, because
the private structure can grow more members as needed. See
-\xref{sec:fixme.compatibility} for more details.
+\xref{sec:fixme.compatibility} for more details.)
\subsubsection{Vtables}
slot containing a function pointer is not at all the same thing as a method.)
\subsubsection{Conversions}
-Suppose one has a value of type pointer to class type of some class~$C$, and
-wants to convert it to a pointer to class type of some other class~$B$.
+Suppose one has a value of type pointer-to-class-type for some class~$C$, and
+wants to convert it to a pointer-to-class-type for some other class~$B$.
There are three main cases to distinguish.
\begin{itemize}
\item If $B$ is a superclass of~$C$, in the same chain, then the conversion
pointer. The conversion can be performed using the appropriate generated
upcast macro (see below); the general case is handled by the macro
\descref{SOD_XCHAIN}{mac}.
-\item If $B$ is a subclass of~$C$ then the conversion is an \emph{upcast};
+\item If $B$ is a subclass of~$C$ then the conversion is a \emph{downcast};
otherwise the conversion is a~\emph{cross-cast}. In either case, the
conversion can fail: the object in question might not be an instance of~$B$
- at all. The macro \descref{SOD_CONVERT}{mac} and the function
+ after all. The macro \descref{SOD_CONVERT}{mac} and the function
\descref{sod_convert}{fun} perform general conversions. They return a null
pointer if the conversion fails. (There are therefore your analogue to the
- \Cplusplus @|dynamic_cast<>| operator.)
+ \Cplusplus\ @|dynamic_cast<>| operator.)
\end{itemize}
The Sod translator generates macros for performing both in-chain and
cross-chain upcasts. For each class~$C$, and each proper superclass~$B$
Details of initialization are necessarily class-specific, but typically it
involves setting the instance's slots to appropriate values, and possibly
-linking it into some larger data structure to keep track of it.
+linking it into some larger data structure to keep track of it. It is
+possible for initialization methods to attempt to allocate resources, but
+this must be done carefully: there is currently no way to report an error
+from object initialization, so the object must be marked as incompletely
+initialized, and left in a state where it will be safe to tear down later.
Initialization is performed by sending the imprinted instance an @|init|
message, defined by the @|SodObject| class. This message uses a nonstandard
\descref{sod_destroy}[function]{fun}.
\subsubsection{Teardown}
-Details of initialization are necessarily class-specific, but typically it
-involves setting the instance's slots to appropriate values, and possibly
-linking it into some larger data structure to keep track of it.
+Details of teardown are necessarily class-specific, but typically it
+involves releasing resources held by the instance, and disentangling it from
+any data structures it might be linked into.
Teardown is performed by sending the instance the @|teardown| message,
defined by the @|SodObject| class. The message returns an integer, used as a
counting system, as follows.
\begin{prog}
[nick = ref] \\
- class ReferenceCountedObject \{ \\ \ind
+ class ReferenceCountedObject: SodObject \{ \\ \ind
unsigned nref = 1; \\-
void inc() \{ me@->ref.nref++; \} \\-
[role = around] \\
~mdw / sod / blobdiff