| 1 | %%% -*-latex-*- |
| 2 | %%% |
| 3 | %%% In-depth exploration of the generated structures |
| 4 | %%% |
| 5 | %%% (c) 2015 Straylight/Edgeware |
| 6 | %%% |
| 7 | |
| 8 | %%%----- Licensing notice --------------------------------------------------- |
| 9 | %%% |
| 10 | %%% This file is part of the Simple Object Definition system. |
| 11 | %%% |
| 12 | %%% SOD is free software; you can redistribute it and/or modify |
| 13 | %%% it under the terms of the GNU General Public License as published by |
| 14 | %%% the Free Software Foundation; either version 2 of the License, or |
| 15 | %%% (at your option) any later version. |
| 16 | %%% |
| 17 | %%% SOD is distributed in the hope that it will be useful, |
| 18 | %%% but WITHOUT ANY WARRANTY; without even the implied warranty of |
| 19 | %%% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| 20 | %%% GNU General Public License for more details. |
| 21 | %%% |
| 22 | %%% You should have received a copy of the GNU General Public License |
| 23 | %%% along with SOD; if not, write to the Free Software Foundation, |
| 24 | %%% Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. |
| 25 | |
| 26 | \chapter{Object structures} \label{ch:structures} |
| 27 | |
| 28 | This chapter describes the structure and layout of standard Sod objects, |
| 29 | classes and associated metadata. Note that Sod's object system is very |
| 30 | flexible and it's possible for an extension to define a new root class which |
| 31 | works very differently from the standard @|SodObject| described here. |
| 32 | |
| 33 | The concrete types described in |
| 34 | \xref[\instead{sections}]{sec:structures.common} and |
| 35 | \ref{sec:structures.root} are declared by the header file |
| 36 | @|<sod/sod.h>|.\footnote{% |
| 37 | This isn't completely true. The @|SodObject| and @|SodClass| structures |
| 38 | are defined in a header called @|<sod/sod-base.h>|, which is generated by |
| 39 | the Sod translator; but @|<sod/sod.h>| includes @|<sod/sod-base.h>|, so you |
| 40 | can forget about this detail.} % |
| 41 | The definitions described in \xref{sec:structures.layout} are defined in the |
| 42 | header file generated by the containing module. |
| 43 | |
| 44 | %%%-------------------------------------------------------------------------- |
| 45 | \section{Common instance structure} \label{sec:structures.common} |
| 46 | |
| 47 | As described below, a pointer to an instance actually points to an |
| 48 | \emph{instance chain} structure within the instances overall layout |
| 49 | structure. |
| 50 | |
| 51 | Instance chains contain slots and vtable pointers, as described below. All |
| 52 | instances have the basic structure of a @|struct sod_instance|. |
| 53 | |
| 54 | \begin{describe}{ty}[struct sod_instance] |
| 55 | {struct sod_instance \{ \\ \ind |
| 56 | const struct sod_vtable *_vt; \-\\ |
| 57 | \};} |
| 58 | |
| 59 | The basic structure of all instances. Members are as follows. |
| 60 | \begin{description} \let\makelabel\code |
| 61 | \item[_vt] A pointer to a \emph{vtable}, which has the basic structure of a |
| 62 | @|struct sod_vtable|, described below. |
| 63 | \end{description} |
| 64 | \end{describe} |
| 65 | |
| 66 | \begin{describe}{ty}[struct sod_vtable] |
| 67 | {struct sod_vtable \{ \\ \ind |
| 68 | const SodClass *_class; \\ |
| 69 | size_t _base; \-\\ |
| 70 | \};} |
| 71 | |
| 72 | A vtable contains static metadata needed for efficient conversions and |
| 73 | message dispatch, and pointers to the instance's class. Each chain points |
| 74 | to a different vtable. All vtables have the basic structure of a @|struct |
| 75 | sod_vtable|, which has the following members. |
| 76 | \begin{description} \let\makelabel\code |
| 77 | \item[_class] A pointer to the instance's class object. |
| 78 | \item[_base] The offset of this chain structure above the start of the |
| 79 | overall instance layout, in bytes. Subtracting @|_base| from the |
| 80 | instance chain pointer finds the layout base address. |
| 81 | \end{description} |
| 82 | \end{describe} |
| 83 | |
| 84 | %%%-------------------------------------------------------------------------- |
| 85 | \section{Built-in root objects} \label{sec:structures.root} |
| 86 | |
| 87 | This section describes the built-in classes @|SodObject| and @|SodClass|, |
| 88 | which are the standard roots of the inheritance and metaclass graphs |
| 89 | respectively. Specifically, @|SodObject| has no direct superclasses, and |
| 90 | @|SodClass| is its own metaclass. It is not possible to define root classes |
| 91 | in module files because of circularities: @|SodObject| has @|SodClass| as its |
| 92 | metaclass, and @|SodClass| is a subclass of @|SodObject|. Extensions can |
| 93 | define additional root classes, but this is tricky, and not really to be |
| 94 | recommended. |
| 95 | |
| 96 | The class definitions shown in the synopses are intended to be informative, |
| 97 | but are fictional and can't really work: these classes are really defined by |
| 98 | Lisp code in the Sod translator, in order to deal with the circularities |
| 99 | involved at the top of the class/metaclass graph (see |
| 100 | \xref{sec:concepts.metaclasses.runtime}). |
| 101 | |
| 102 | |
| 103 | \subsection{The SodObject class} \label{sec:structures.root.sodobject} |
| 104 | |
| 105 | \begin{figure}[tbp] |
| 106 | \begin{tabular}{p{10pt}p{10pt}} |
| 107 | \begin{nprog} |
| 108 | struct SodObject__ilayout \{ \\ \ind |
| 109 | union \{ \\ \ind |
| 110 | struct SodObject__ichain_obj \{ \\ \ind |
| 111 | const struct SodObject__vt_obj *_vt; \-\\ |
| 112 | \} obj; \-\\ |
| 113 | \} obj; \-\\ |
| 114 | \}; |
| 115 | \end{nprog} |
| 116 | & |
| 117 | \begin{nprog} |
| 118 | struct SodObject__vt_obj \{ \\ \ind |
| 119 | const SodClass *_class; \\ |
| 120 | size_t _base; \\ |
| 121 | struct SodObject__vtmsgs_obj \{ \\ \ind |
| 122 | void (*init)(SodObject *me, ...); \\ |
| 123 | void (*init__v)(SodObject *me, va_list); \\ |
| 124 | int (*teardown)(SodObject *me); \-\\ |
| 125 | \} obj; \-\\ |
| 126 | \}; |
| 127 | \end{nprog} \\ |
| 128 | \end{tabular} |
| 129 | \caption{Instance and vtable layout of @|SodObject|} |
| 130 | \label{fig:structures.root.sodobject} |
| 131 | \end{figure} |
| 132 | |
| 133 | \begin{describe}{cls}[SodObject] |
| 134 | {[nick = obj, metaclass = SodClass, |
| 135 | lisp_metaclass = sod_class] \\ |
| 136 | class SodObject \{ \\ \ind |
| 137 | void init(?); \-\\ |
| 138 | \}} |
| 139 | |
| 140 | The @|SodObject| class defines no slots. Because @|SodObject| has no |
| 141 | direct superclasses, there is only one chain, and no inherited slots or |
| 142 | messages, so the single chain contains only a vtable pointer. |
| 143 | |
| 144 | Since @|SodClass| also has only one chain, the vtable contains only the |
| 145 | standard class pointer and offset-to-base members. In a direct instance of |
| 146 | @|SodObject| (why would you want one?) the class pointer contains the |
| 147 | address of @|SodObject__class| and the offset is zero. |
| 148 | |
| 149 | The instance and vtable layout of @|SodObject| is shown in |
| 150 | \xref{fig:structures.root.sodobject}. |
| 151 | |
| 152 | The following messages are defined. |
| 153 | |
| 154 | \begin{describe}{msg}[obj.init]{void init(?);} |
| 155 | Initialize a newly allocated instance. |
| 156 | |
| 157 | This message uses a custom method combination which works like the |
| 158 | standard method combination except that default behaviour specific to the |
| 159 | receiver's direct class is invoked if no primary or around method |
| 160 | overrides. This default behaviour may be invoked multiple times if some |
| 161 | method calls on its @|next_method| function more than once. |
| 162 | |
| 163 | This default behaviour is to initialize the instance's slots using the |
| 164 | defined slot initializers, and execute the initialization fragments. |
| 165 | Each slot is initialized using the most specific applicable initializer, |
| 166 | if any. Slots without an initializer are left uninitialized. |
| 167 | |
| 168 | Slots are initialized and initialization fragments executed together, a |
| 169 | superclass at a time: first, the superclass's slots are initialized (if |
| 170 | any); then the superclass's initialization fragments (if any) are |
| 171 | executed, starting with the least specific superclass first. Slots and |
| 172 | initialization fragments defined by the same class are processed in the |
| 173 | order in which they appear in the class definition. |
| 174 | |
| 175 | There are no standard keyword arguments; methods on subclasses are free |
| 176 | to introduce their own in the usual way. |
| 177 | |
| 178 | It is usual to provide complex initialization behaviour as @|after| |
| 179 | methods. This ensures that slots have been initialized as necessary |
| 180 | before the method executes. |
| 181 | |
| 182 | For more details on instance construction, see |
| 183 | \xref{sec:concepts.lifecycle.birth}. |
| 184 | \end{describe} |
| 185 | |
| 186 | \begin{describe}{msg}[obj.teardown]{int teardown();} |
| 187 | Teardown an instance which is no longer required. |
| 188 | |
| 189 | The message returns an integer flag. A zero value means that the |
| 190 | instance is safe to deallocate. A nonzero value means that the instance |
| 191 | should not be deallocated, and that it is safe for the caller to simply |
| 192 | forget about it. This simple protocol may be used, for example, to |
| 193 | implement a reference-counting system. |
| 194 | |
| 195 | This message uses a custom method combination which works like the |
| 196 | standard method combination except that default behaviour is invoked if |
| 197 | no primary or around method overrides. |
| 198 | |
| 199 | This default behaviour is to execute each superclass's teardown |
| 200 | fragments, most specific first, and then return zero to indicate that the |
| 201 | object is ready for deallocation. Teardown fragments defined by the same |
| 202 | class are processed in the order in which they appear in the class |
| 203 | definition. |
| 204 | |
| 205 | It is usual to provide complex teardown behaviour as @|before| methods. |
| 206 | Logic to decide whether to allow deallocation is usually implemented as |
| 207 | @|around| methods. |
| 208 | \end{describe} |
| 209 | \end{describe} |
| 210 | |
| 211 | |
| 212 | \subsection{The SodClass class} \label{sec:structures.root.sodclass} |
| 213 | |
| 214 | \begin{describe}{cls}[SodClass] |
| 215 | {[nick = cls, link = SodObject] \\ |
| 216 | class SodClass: SodObject \{ \\ \ind |
| 217 | const char *name; \\ |
| 218 | const char *nick; \\ |
| 219 | size_t initsz; \\ |
| 220 | size_t align; \\ |
| 221 | void *(*imprint)(void *@<p>); \\ |
| 222 | size_t n_supers; \\ |
| 223 | const SodClass *const *supers; \\ |
| 224 | size_t n_cpl; \\ |
| 225 | const SodClass *const *cpl; \\ |
| 226 | const SodClass *link; \\ |
| 227 | const SodClass *head; \\ |
| 228 | size_t level; \\ |
| 229 | size_t n_chains; \\ |
| 230 | const struct sod_chain *chains; \\ |
| 231 | size_t off_islots; \\ |
| 232 | size_t islotsz; \-\\ |
| 233 | \}} |
| 234 | |
| 235 | The @|SodClass| class defines no additional messages , but there are a |
| 236 | number of slots. Its only direct superclass is @|SodObject| and so (like |
| 237 | its superclass) its vtable is simple. |
| 238 | |
| 239 | The slots defined are as follows. |
| 240 | \begin{description} \let\makelabel\code |
| 241 | |
| 242 | \item[name] A pointer to the class's name. |
| 243 | |
| 244 | \item[nick] A pointer to the class's nickname. |
| 245 | |
| 246 | \item[initsz] The size in bytes required to store an instance of the class. |
| 247 | |
| 248 | \item[align] A sufficient alignment for the class's instance storage. |
| 249 | |
| 250 | \item[imprint] A pointer to a function: given a pointer @<p> to at least |
| 251 | @<initsz> bytes of appropriately aligned memory, `imprint' this memory it |
| 252 | so that it becomes a minimally functional instance of the class: all of |
| 253 | the vtable and class pointers are properly initialized, but the slots are |
| 254 | left untouched. The function returns its argument @<p>. |
| 255 | |
| 256 | \item[n_supers] The number of direct superclasses. (This is zero exactly |
| 257 | in the case of @|SodObject|.) |
| 258 | |
| 259 | \item[supers] A pointer to an array of @<n_supers> pointers to class |
| 260 | objects listing the class's direct superclasses, in the order in which |
| 261 | they were listed in the class definition. If @<n_supers> is zero, then |
| 262 | this pointer is null. |
| 263 | |
| 264 | \item[n_cpl] The number of superclasses in the class's class precedence |
| 265 | list. |
| 266 | |
| 267 | \item[cpl] A pointer to an array of pointers to class objects listing all |
| 268 | of the class's superclasses, from most- to least-specific, starting with |
| 269 | the class itself, so $@|$c$@->cls.cpl[0]| = c$ for all class objects |
| 270 | $c$. |
| 271 | |
| 272 | \item[link] If the class is a chain head, then this is a null pointer; |
| 273 | otherwise it points to the class's distinguished link superclass (which |
| 274 | might or might not be a direct superclass). |
| 275 | |
| 276 | \item[head] A pointer to the least-specific class in this class's chain; so |
| 277 | @|$c$@->cls.head@->cls.link| is always null, and either @|$c$@->cls.link| |
| 278 | is null (in which case $@|$c$@->cls.head| = c$) or $@|$c$@->cls.head| = |
| 279 | @|$c$@->cls.link@->cls.head|$. |
| 280 | |
| 281 | \item[level] The number of less specific superclasses in this class's |
| 282 | chain. If @|$c$@->cls.link| is null then @|$c$@->cls.level| is zero; |
| 283 | otherwise $@|$c$@->cls.level| = @|$c$@->cls.link@->cls.level| + 1$. |
| 284 | |
| 285 | \item[n_chains] The number of chains formed by the class's superclasses. |
| 286 | |
| 287 | \item[chains] A pointer to an array of @|struct sod_chain| structures (see |
| 288 | below) describing the class's superclass chains, in decreasing order of |
| 289 | specificity of their most specific classes. It is always the case that |
| 290 | $@|$c$@->cls.chains[0].classes[$c$@->cls.level]| = c$. |
| 291 | |
| 292 | \item[off_islots] The offset of the class's @|islots| structure relative to |
| 293 | its containing @|ichain| structure. The class doesn't define any slots |
| 294 | if and only if this is zero. (The offset can't be zero because the |
| 295 | vtable pointer is at offset zero.) |
| 296 | |
| 297 | \item[islotsz] The size required to store the class's direct slots, i.e., |
| 298 | the size of its @|islots| structure. The class doesn't define any slots |
| 299 | if and only if this is zero. |
| 300 | |
| 301 | \end{description} |
| 302 | \end{describe} |
| 303 | |
| 304 | \begin{describe}{ty}[struct sod_chain] |
| 305 | {struct sod_chain \{ \\ \ind |
| 306 | size_t n_classes; \\ |
| 307 | const SodClass *const *classes; \\ |
| 308 | size_t off_ichain; \\ |
| 309 | const struct sod_vtable *vt; \\ |
| 310 | size_t ichainsz; \-\\ |
| 311 | \};} |
| 312 | |
| 313 | The @|struct sod_chain| structure describes an individual chain of |
| 314 | superclasses. It has the following members. |
| 315 | \begin{description} \let\makelabel\code |
| 316 | |
| 317 | \item[n_classes] The number of classes in the chain. This is always at |
| 318 | least one. |
| 319 | |
| 320 | \item[classes] A pointer to an array of class pointers listing the classes |
| 321 | in the chain from least- to most-specific. So |
| 322 | $@|@<classes>[$i$]@->cls.head| = @|@<classes>[0]|$ for all $0 \le i < |
| 323 | @<n_classes>$, @|@<classes>[0]@->cls.link| is always null, and |
| 324 | $@|@<classes>[$i$]@->cls.link| = @|@<classes>[$i - 1$]|$ if $1 \le i < |
| 325 | @<n_classes>$. |
| 326 | |
| 327 | \item[off_ichain] The size of the @|ichain| structure for this chain. |
| 328 | |
| 329 | \item[vt] The vtable for this chain. (It is possible, therefore, to |
| 330 | partially duplicate the behaviour of the @<imprint> function by walking |
| 331 | the chain structure.\footnote{% |
| 332 | There isn't enough information readily available to fill in the class |
| 333 | pointers correctly.} % |
| 334 | The @<imprint> function is much faster, though.) |
| 335 | |
| 336 | \item[ichainsz] The size of the @|ichain| structure for this chain. |
| 337 | |
| 338 | \end{description} |
| 339 | \end{describe} |
| 340 | |
| 341 | %%%-------------------------------------------------------------------------- |
| 342 | \section{Class and vtable layout} \label{sec:structures.layout} |
| 343 | |
| 344 | The layout algorithms for Sod instances and vtables are nontrivial. They are |
| 345 | defined here in full detail, since they're effectively fixed by Sod's ABI |
| 346 | compatibility guarantees, so they might as well be documented for the sake of |
| 347 | interoperating programs. |
| 348 | |
| 349 | Unfortunately, the descriptions are rather complicated, and, for the most |
| 350 | part not necessary to a working understanding of Sod. The skeleton structure |
| 351 | definitions shown should be more than enough for readers attempting to make |
| 352 | sense of the generated headers and tables. |
| 353 | |
| 354 | In the description that follows, uppercase letters vary over class names, |
| 355 | while the corresponding lowercase letters indicate the class nicknames. |
| 356 | Throughout, we consider a class $C$ (therefore with nickname $c$). |
| 357 | |
| 358 | |
| 359 | \subsection{Generic instance structure} |
| 360 | \label{sec:structures.layout.instance} |
| 361 | |
| 362 | The entire state of an instance of $C$ is contained in a single structure of |
| 363 | type @|struct $C$__ilayout|. |
| 364 | |
| 365 | \begin{prog} |
| 366 | struct $C$__ilayout \{ \\ \ind |
| 367 | union $C$__ichainu_$h$ \{ \\ \ind |
| 368 | struct $C$__ichain_$h$ \{ \\ \ind |
| 369 | const struct $C$__vt_$h$ *_vt; \\ |
| 370 | struct $H$__islots $h$; \\ |
| 371 | \quad$\vdots$ \\ |
| 372 | struct $C$__islots \{ \\ \ind |
| 373 | @<type>_1 @<slot>_1; \\ |
| 374 | \quad$\vdots$ \\ |
| 375 | @<type>_n @<slot>_n; \-\\ |
| 376 | \} $c$; \-\\ |
| 377 | \} $c$; \\ |
| 378 | struct $A$__ichain_$h$ $a$; \\ |
| 379 | \quad$\vdots$ \-\\ |
| 380 | \} $h$; \\ |
| 381 | union $B$__ichainu_$i$ $i$; \\ |
| 382 | \quad$\vdots$ \-\\ |
| 383 | \}; \\+ |
| 384 | |
| 385 | typedef struct $C$__ichain_$h$ $C$; |
| 386 | \end{prog} |
| 387 | |
| 388 | The set of superclasses of $C$, including itself, can be partitioned into |
| 389 | chains by following their distinguished superclass links. (Formally, the |
| 390 | chains are the equivalence classes determined by the reflexive, symmetric, |
| 391 | transitive closure of the `links to' relation.) Chains are identified by |
| 392 | naming their least specific classes; the least specific class in a chain is |
| 393 | called the \emph{chain head}. Suppose that the chain head of the chain |
| 394 | containing $C$ itself is named $H$ (though keep in mind that it's possible |
| 395 | that $H$ is in fact $C$ itself.) |
| 396 | |
| 397 | \subsubsection{The ilayout structure} |
| 398 | The @|ilayout| structure contains one member for each of $C$'s superclass |
| 399 | chains. The first such member is |
| 400 | \begin{prog} |
| 401 | union $C$__ichainu_$h$ $h$; |
| 402 | \end{prog} |
| 403 | described below; this is followed by members |
| 404 | \begin{prog} |
| 405 | union $B$__ichainu_$i$ $i$; |
| 406 | \end{prog} |
| 407 | for each other chain, where $I$ is the head and $B$ the tail (most-specific) |
| 408 | class of the chain. The members are in decreasing order of the specificity |
| 409 | of the chains' most-specific classes. (Note that all but the first of these |
| 410 | unions has already been defined as part of the definition of the |
| 411 | corresponding $B$.) |
| 412 | |
| 413 | \subsubsection{The ichainu union} |
| 414 | The @|ichainu| union contains a member for each class in the chain. The |
| 415 | first is |
| 416 | \begin{prog} |
| 417 | struct $C$__ichain_$h$ $c$; |
| 418 | \end{prog} |
| 419 | and this is followed by corresponding members |
| 420 | \begin{prog} |
| 421 | struct $A$__ichain_$h$ $a$; |
| 422 | \end{prog} |
| 423 | for each of $C$'s superclasses $A$ in the same chain in some (unimportant) |
| 424 | order. The (somewhat obtuse) purpose of this union is to engage the `common |
| 425 | initial sequence' rule of \cite[6.5.2.3]{ISO:1990:IIP,ANSI:1999:AII}. |
| 426 | |
| 427 | \subsubsection{The ichain structure} |
| 428 | The @|ichain| structure contains (in order), a pointer |
| 429 | \begin{prog} |
| 430 | const struct $C$__vt_$h$ *_vt; |
| 431 | \end{prog} |
| 432 | followed by a structure |
| 433 | \begin{prog} |
| 434 | struct $A$__islots $a$; |
| 435 | \end{prog} |
| 436 | for each superclass $A$ of $C$ in the same chain which defines slots, from |
| 437 | least- to most-specific; if $C$ defines any slots, then the last member is |
| 438 | \begin{prog} |
| 439 | struct $C$__islots $c$; |
| 440 | \end{prog} |
| 441 | A `pointer to $C$' is always assumed (and, indeed, defined in C's |
| 442 | type system) to be a pointer to the @|struct $C$__ichain_$h$|. |
| 443 | |
| 444 | \subsubsection{The islots structure} |
| 445 | Finally, the @|islots| structure simply contains one member for each slot |
| 446 | defined by $C$ in the order they appear in the class definition. |
| 447 | |
| 448 | |
| 449 | \subsection{Generic vtable structure} \label{sec:structures.layout.vtable} |
| 450 | |
| 451 | As described above, each @|ichain| structure of an instance's storage has a |
| 452 | vtable pointer |
| 453 | \begin{prog} |
| 454 | const struct $C$__vt_$h$ *_vt; |
| 455 | \end{prog} |
| 456 | In general, the vtables for the different chains will have \emph{different} |
| 457 | structures. |
| 458 | |
| 459 | The instance layout splits neatly into disjoint chains. This is necessary |
| 460 | because each @|ichain| must have as a prefix the @|ichain| for each |
| 461 | superclass in the same chain, and each slot must be stored in exactly one |
| 462 | place. The layout of vtables doesn't have this second requirement: it |
| 463 | doesn't matter that there are multiple method entry pointers for the same |
| 464 | effective method as long as they all work correctly. Indeed, it's essential |
| 465 | that there are multiple entry pointers, because each chain's method entry |
| 466 | function will need to apply a different offset to the receiver pointer before |
| 467 | invoking the effective method. |
| 468 | |
| 469 | A vtable for a class $C$ with chain head $H$ has the following general |
| 470 | structure. |
| 471 | \begin{prog} |
| 472 | union $C$__vtu_$h$ \{ \\ \ind |
| 473 | struct $C$__vt_$h$ \{ \\ \ind |
| 474 | const $P$ *_class; \\ |
| 475 | size_t _base; \\ |
| 476 | \quad$\vdots$ \\ |
| 477 | const $Q$ *_cls_$j$; \\ |
| 478 | \quad$\vdots$ \\ |
| 479 | ptrdiff_t _off_$i$; \\ |
| 480 | \quad$\vdots$ \\ |
| 481 | struct $C$__vtmsgs_$a$ \{ \\ \ind |
| 482 | @<type> (*@<msg>)($C$ *, $\dots$); \\ |
| 483 | \quad$\vdots$ \-\\ |
| 484 | \} $a$; \\ |
| 485 | \quad$\vdots$ \-\\ |
| 486 | \} $c$; \-\\ |
| 487 | \}; \\+ |
| 488 | |
| 489 | extern const union $C$__vtu_$h$ $C$__vtable_$h$; |
| 490 | \end{prog} |
| 491 | |
| 492 | In the following, let $M$ be the metaclass of $C$. |
| 493 | |
| 494 | \subsubsection{The vtu union} |
| 495 | The outer layer is a @|union $C$__vtu_$h$| containing a member |
| 496 | \begin{prog} |
| 497 | struct $A$__vt_$h$ $a$; |
| 498 | \end{prog} |
| 499 | for each of $C$'s superclasses $A$ in the same chain, with $C$ itself listed |
| 500 | first. |
| 501 | |
| 502 | This is mostly an irrelevant detail, whose purpose is to defend against |
| 503 | malicious compilers: pointers are always to one of the inner @|vt| |
| 504 | structures. It's important only because it's the outer @|vtu| union which is |
| 505 | exported by name. Specifically, for each chain of $C$'s superclasses there |
| 506 | is an external object |
| 507 | \begin{prog} |
| 508 | const union $A$__vtu_$i$ $C$__vtable_$i$; |
| 509 | \end{prog} |
| 510 | where $A$ and $I$ are respectively the most and least specific classes in the |
| 511 | chain. |
| 512 | |
| 513 | \subsubsection{The vt structure} |
| 514 | The first member in the @|vt| structure is the \emph{root class pointer} |
| 515 | \begin{prog} |
| 516 | const $P$ *_class; |
| 517 | \end{prog} |
| 518 | Among the superclasses of $C$ there must be exactly one class $O$ which |
| 519 | itself has no direct superclasses; this is the \emph{root superclass} of $C$. |
| 520 | (This is a rule enforced by the Sod translator.) The metaclass $R$ of $O$ is |
| 521 | then the \emph{root metaclass} of $C$. The @|_class| member points to the |
| 522 | @|ichain| structure of most specific superclass $P$ of $M$ in the same chain |
| 523 | as $R$. |
| 524 | |
| 525 | This is followed by the \emph{base offset} |
| 526 | \begin{prog} |
| 527 | size_t _base; |
| 528 | \end{prog} |
| 529 | which is simply the offset of the @|ichain| structure from the instance base. |
| 530 | |
| 531 | The rest of the vtable structure is populated by walking the superclass chain |
| 532 | containing $C$ as follows. For each such superclass $B$, in increasing order |
| 533 | of specificity, walk the class precedence list of $B$, again starting with |
| 534 | its least-specific superclass. (This complex procedure guarantees that the |
| 535 | vtable structure for a class is a prefix of the vtable structure for any of |
| 536 | its subclasses in the same chain.) |
| 537 | |
| 538 | So, let $A$ be some superclass of $C$ which has been encountered during this |
| 539 | traversal. |
| 540 | |
| 541 | \begin{itemize} |
| 542 | |
| 543 | \item Let $N$ be the metaclass of $A$. Examine the superclass chains of $N$ |
| 544 | in order of decreasing specificity of their most-specific classes. Let $J$ |
| 545 | be the chain head of such a chain. If there is currently no class pointer |
| 546 | for the chain headed by $J$, then add a member |
| 547 | \begin{prog} |
| 548 | const $Q$ *_cls_$j$; |
| 549 | \end{prog} |
| 550 | to the vtable pointing to the appropriate @|islots| structure within $M$'s |
| 551 | class object, where $Q$ is the most specific superclass of $M$ in the same |
| 552 | chain as $J$. |
| 553 | |
| 554 | \item Examine the superclass chains of $A$ in order of decreasing specificity |
| 555 | of their most-specific classes. Let $I$ be the chain head of such a chain. |
| 556 | If there is currently no member @|_off_$i$| then add a member |
| 557 | \begin{prog} |
| 558 | ptrdiff_t _off_$i$; |
| 559 | \end{prog} |
| 560 | to the vtable, containing the (signed) offset from the @|ichain| structure |
| 561 | of the chain headed by $h$ to that of the chain headed by $i$ within the |
| 562 | instance's layout. |
| 563 | |
| 564 | \item If class $A$ defines any messages, and there is currently no member |
| 565 | $a$, then add a member |
| 566 | \begin{prog} |
| 567 | struct $C$__vtmsgs_$a$ $a$; |
| 568 | \end{prog} |
| 569 | to the vtable. See below. |
| 570 | |
| 571 | \end{itemize} |
| 572 | |
| 573 | \subsubsection{The vtmsgs structure} |
| 574 | Finally, the @|vtmsgs| structures contain pointers to the effective method |
| 575 | entry functions for the messages defined by a superclass. There may be more |
| 576 | than one method entry for a message, but all of the entry pointers for a |
| 577 | message appear together, and entry pointers for separate messages appear in |
| 578 | the order in which the messages are defined. If the receiver class has no |
| 579 | applicable primary method for a message then it's usual for the method entry |
| 580 | pointer to be null (though, as with a lot of things in Sod, extensions may do |
| 581 | something different). |
| 582 | |
| 583 | For a standard message which takes a fixed number of arguments, defined as |
| 584 | \begin{prog} |
| 585 | @<type>_0 $m$(@<type>_1 @<arg>_1, $\ldots$, @<type>_n @<arg>_n); |
| 586 | \end{prog} |
| 587 | there is always a `main' entry point, |
| 588 | \begin{prog} |
| 589 | @<type>_0 $m$($C$ *me, @<type>_1 @<arg>_1, $\ldots$, @<type>_n @<arg>_n); |
| 590 | \end{prog} |
| 591 | |
| 592 | For a standard message which takes a variable number of arguments, |
| 593 | defined as |
| 594 | \begin{prog} |
| 595 | @<type>_0 $m$(@<type>_1 @<arg>_1, $\ldots$, @<type>_n @<arg>_n, \dots); |
| 596 | \end{prog} |
| 597 | or a standard message which takes keyword arguments, defined as |
| 598 | \begin{prog} |
| 599 | @<type>_0 $m$(\=@<type>_1 @<arg>_1, |
| 600 | $\ldots$, |
| 601 | @<type>_n @<arg>_n? \+\\ |
| 602 | @<type>_{n+1} @<kw>_{n+1} @[= @<dflt>_{n+1}@], |
| 603 | $\ldots$, |
| 604 | @<type>_{n'} @<kw>_{n'} @[= @<dflt>_{n'}@]); |
| 605 | \end{prog} |
| 606 | two entry points are defined: the usual `main' entry point which accepts a |
| 607 | variable number of arguments, and a `valist' entry point which accepts an |
| 608 | argument of type @|va_list| in place of the variable portion of the argument |
| 609 | list or keywords. |
| 610 | \begin{prog} |
| 611 | @<type>_0 $m$($C$ *me, @<type>_1 @<arg>_1, $\ldots$, |
| 612 | @<type>_n @<arg>_n, \dots); \\ |
| 613 | @<type>_0 $m$__v($C$ *me, @<type>_1 @<arg>_1, $\ldots$, |
| 614 | @<type>_n @<arg>_n, va_list sod__ap); |
| 615 | \end{prog} |
| 616 | |
| 617 | |
| 618 | \subsection{Additional definitions} \label{sec:structures.layout.additional} |
| 619 | |
| 620 | In addition to the instance and vtable structures described above, the |
| 621 | following definitions are made for each class $C$. |
| 622 | |
| 623 | For each message $m$ directly defined by $C$ there is a macro definition |
| 624 | \begin{prog} |
| 625 | \#define $C$_$m$(@<me>, $\ldots$) @<me>@->_vt@->$c$.$m$(@<me>, $\ldots$) |
| 626 | \end{prog} |
| 627 | which makes sending the message $m$ to an instance of (any subclass of) $C$ |
| 628 | somewhat less ugly. |
| 629 | |
| 630 | If $m$ takes a variable number of arguments, or keyword arguments, the macro |
| 631 | is more complicated and is only available in compilers advertising C99 |
| 632 | support, but the effect is the same. For each variable-argument message, |
| 633 | there is also an additional macro for calling the `valist' entry point. |
| 634 | \begin{prog} |
| 635 | \#define $C$_$m$__v(@<me>, $\ldots$, @<sod__ap>) |
| 636 | @<me>@->_vt@->$c$.$m$__v(@<me>, $\ldots$, @<sod__ap>) |
| 637 | \end{prog} |
| 638 | |
| 639 | For each proper superclass $A$ of $C$, there is a macro defined |
| 640 | \begin{prog} |
| 641 | $A$ *$C$__CONV_$a$($C$ *_obj); |
| 642 | \end{prog} |
| 643 | (named in \emph{upper case}) which converts a (static-type) pointer to $C$ to |
| 644 | a pointer to the same actual instance, but statically typed as a pointer to |
| 645 | $A$. This is most useful when $A$ is not in the same chain as $C$ since |
| 646 | in-chain upcasts are both trivial and rarely needed, but the full set is |
| 647 | defined for the sake of completeness. |
| 648 | |
| 649 | Finally, the class object is defined as |
| 650 | \begin{prog} |
| 651 | extern const struct $R$__ilayout $C$__classobj; \\ |
| 652 | \#define $C$__class (\&$C$__classobj.$j$.$r$) \\ |
| 653 | \#define $C$__cls_$k$ (\&$C$__classobj.$k$.$n$) \\ |
| 654 | \quad$\vdots$ |
| 655 | \end{prog} |
| 656 | The exported symbol @|$C$__classobj| contains the entire class instance. |
| 657 | This is usually rather unwieldy. The macro @|$C$__class| is usable as a |
| 658 | pointer of type @|const $R$~*|, where $R$ is the root metaclass of $C$, i.e., |
| 659 | the metaclass of the least specific superclass of $C$; usually this is |
| 660 | @|const SodClass~*|. For each chain of $C$'s metaclass, a macro |
| 661 | @|$C$__cls_$k$| is defined, usable as a pointer of type @|const $N$~*|, where |
| 662 | $K$ and $N$ are the chain's head and tail classes (i.e., the least- and |
| 663 | most-specific classes in the chain) respectively; this macro is |
| 664 | \emph{omitted} if $N = R$, i.e., in the common case where $C$'s metaclass is |
| 665 | precisely the root metaclass, since the existing @|$C$__class| macro is |
| 666 | already sufficient. |
| 667 | |
| 668 | |
| 669 | %%%----- That's all, folks -------------------------------------------------- |
| 670 | |
| 671 | %%% Local variables: |
| 672 | %%% mode: LaTeX |
| 673 | %%% TeX-master: "sod.tex" |
| 674 | %%% TeX-PDF-mode: t |
| 675 | %%% End: |