Commit | Line | Data |
---|---|---|
62f9852b MW |
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 | ||
ca2023b8 MW |
33 | The concrete types described in |
34 | \xref[\instead{sections}]{sec:structures.common} and | |
b885da9c MW |
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.} % | |
43073476 MW |
41 | The definitions described in \xref{sec:structures.layout} are defined in the |
42 | header file generated by the containing module. | |
62f9852b MW |
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 | |
9caad6bd MW |
52 | instances have the basic structure of a @|struct sod_instance|. |
53 | ||
ff1f7b21 | 54 | \begin{describe}{ty}[struct sod_instance] |
020b9e2b MW |
55 | {struct sod_instance \{ \\ \ind |
56 | const struct sod_vtable *_vt; \-\\ | |
9caad6bd MW |
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 | ||
ff1f7b21 | 66 | \begin{describe}{ty}[struct sod_vtable] |
020b9e2b MW |
67 | {struct sod_vtable \{ \\ \ind |
68 | const SodClass *_class; \\ | |
69 | size_t _base; \-\\ | |
9caad6bd MW |
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} | |
62f9852b MW |
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 | ||
4faea17d MW |
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 | ||
0a2d4b68 | 102 | |
62f9852b MW |
103 | \subsection{The SodObject class} \label{sec:structures.root.sodobject} |
104 | ||
9caad6bd MW |
105 | \begin{figure}[tbp] |
106 | \begin{tabular}{p{10pt}p{10pt}} | |
4effe575 | 107 | \begin{nprog} |
020b9e2b MW |
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; \-\\ | |
9caad6bd | 114 | \}; |
4effe575 | 115 | \end{nprog} |
9caad6bd | 116 | & |
4effe575 | 117 | \begin{nprog} |
020b9e2b MW |
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; \-\\ | |
9caad6bd | 126 | \}; |
020b9e2b | 127 | \end{nprog} \\ |
9caad6bd MW |
128 | \end{tabular} |
129 | \caption{Instance and vtable layout of @|SodObject|} | |
130 | \label{fig:structures.root.sodobject} | |
131 | \end{figure} | |
132 | ||
34042b35 | 133 | \begin{describe}{cls}[SodObject] |
020b9e2b MW |
134 | {[nick = obj, metaclass = SodClass, |
135 | lisp_metaclass = sod_class] \\ | |
136 | class SodObject \{ \\ \ind | |
2f1ed4eb | 137 | void init(?); \-\\ |
a142609c | 138 | \}} |
9caad6bd | 139 | |
a142609c MW |
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. | |
9caad6bd | 143 | |
a142609c MW |
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. | |
9caad6bd MW |
148 | |
149 | The instance and vtable layout of @|SodObject| is shown in | |
150 | \xref{fig:structures.root.sodobject}. | |
a142609c | 151 | |
a42893dd | 152 | The following messages are defined. |
a142609c | 153 | |
34042b35 | 154 | \begin{describe}{msg}[obj.init]{void init(?);} |
a142609c MW |
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 | |
a42893dd MW |
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. | |
a142609c | 167 | |
a42893dd MW |
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. | |
27ec3825 | 174 | |
a142609c MW |
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} | |
a42893dd | 185 | |
34042b35 | 186 | \begin{describe}{msg}[obj.teardown]{int teardown();} |
a42893dd MW |
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} | |
9caad6bd | 209 | \end{describe} |
62f9852b | 210 | |
0a2d4b68 | 211 | |
62f9852b MW |
212 | \subsection{The SodClass class} \label{sec:structures.root.sodclass} |
213 | ||
34042b35 | 214 | \begin{describe}{cls}[SodClass] |
020b9e2b | 215 | {[nick = cls, link = SodObject] \\ |
fd040f06 | 216 | class SodClass: SodObject \{ \\ \ind |
020b9e2b MW |
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; \-\\ | |
9caad6bd MW |
233 | \}} |
234 | ||
a142609c MW |
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. | |
9caad6bd MW |
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 | ||
8c2c58ae MW |
248 | \item[align] A sufficient alignment for the class's instance storage. |
249 | ||
9caad6bd MW |
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 | ||
9caad6bd MW |
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 | |
ac8ddb83 | 269 | the class itself, so $@|$c$@->cls.cpl[0]| = c$ for all class objects |
9caad6bd MW |
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 | |
ac8ddb83 MW |
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|$. | |
9caad6bd MW |
280 | |
281 | \item[level] The number of less specific superclasses in this class's | |
ac8ddb83 MW |
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$. | |
9caad6bd MW |
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 | |
ac8ddb83 | 290 | $@|$c$@->cls.chains[0].classes[$c$@->cls.level]| = c$. |
9caad6bd MW |
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 | ||
ff1f7b21 | 304 | \begin{describe}{ty}[struct sod_chain] |
020b9e2b MW |
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; \-\\ | |
9caad6bd MW |
311 | \};} |
312 | ||
b5229c16 MW |
313 | The @|struct sod_chain| structure describes an individual chain of |
314 | superclasses. It has the following members. | |
315 | \begin{description} \let\makelabel\code | |
9caad6bd | 316 | |
b5229c16 MW |
317 | \item[n_classes] The number of classes in the chain. This is always at |
318 | least one. | |
9caad6bd | 319 | |
b5229c16 MW |
320 | \item[classes] A pointer to an array of class pointers listing the classes |
321 | in the chain from least- to most-specific. So | |
ac8ddb83 MW |
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 < | |
b5229c16 | 325 | @<n_classes>$. |
9caad6bd | 326 | |
b5229c16 | 327 | \item[off_ichain] The size of the @|ichain| structure for this chain. |
9caad6bd | 328 | |
b5229c16 MW |
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.) | |
9caad6bd | 335 | |
b5229c16 | 336 | \item[ichainsz] The size of the @|ichain| structure for this chain. |
9caad6bd | 337 | |
b5229c16 MW |
338 | \end{description} |
339 | \end{describe} | |
62f9852b MW |
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 | ||
0a2d4b68 | 358 | |
62f9852b MW |
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} | |
020b9e2b MW |
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$; \\ | |
faf3eb58 | 378 | struct $A$__ichain_$h$ $a$; \\ |
020b9e2b MW |
379 | \quad$\vdots$ \-\\ |
380 | \} $h$; \\ | |
381 | union $B$__ichainu_$i$ $i$; \\ | |
382 | \quad$\vdots$ \-\\ | |
383 | \}; \\+ | |
384 | ||
62f9852b MW |
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 | |
02840f3d | 395 | that $H$ is in fact $C$ itself.) |
62f9852b MW |
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) | |
f9bc613c | 424 | order. The (somewhat obtuse) purpose of this union is to engage the `common |
9cd5cf15 | 425 | initial sequence' rule of \cite[6.5.2.3]{ISO:1990:IIP,ANSI:1999:AII}. |
62f9852b MW |
426 | |
427 | \subsubsection{The ichain structure} | |
e97b1677 | 428 | The @|ichain| structure contains (in order), a pointer |
62f9852b MW |
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 | ||
0a2d4b68 | 448 | |
62f9852b MW |
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 | ||
756e9293 | 459 | The instance layout splits neatly into disjoint chains. This is necessary |
62f9852b MW |
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 | |
74bf1b29 MW |
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. | |
62f9852b MW |
468 | |
469 | A vtable for a class $C$ with chain head $H$ has the following general | |
470 | structure. | |
471 | \begin{prog} | |
020b9e2b MW |
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 | ||
62f9852b MW |
489 | extern const union $C$__vtu_$h$ $C$__vtable_$h$; |
490 | \end{prog} | |
491 | ||
fa388683 MW |
492 | In the following, let $M$ be the metaclass of $C$. |
493 | ||
62f9852b MW |
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 | ||
02840f3d MW |
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| | |
f231c300 MW |
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 | |
62f9852b MW |
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$ | |
9a9a7b35 MW |
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 | |
62f9852b MW |
547 | \begin{prog} |
548 | const $Q$ *_cls_$j$; | |
549 | \end{prog} | |
550 | to the vtable pointing to the appropriate @|islots| structure within $M$'s | |
9a9a7b35 MW |
551 | class object, where $Q$ is the most specific superclass of $M$ in the same |
552 | chain as $J$. | |
62f9852b MW |
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} | |
43073476 MW |
597 | or a standard message which takes keyword arguments, defined as |
598 | \begin{prog} | |
020b9e2b MW |
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$, | |
d47e7cbb | 604 | @<type>_{n'} @<kw>_{n'} @[= @<dflt>_{n'}@]); |
43073476 | 605 | \end{prog} |
62f9852b MW |
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 | |
43073476 | 609 | list or keywords. |
62f9852b MW |
610 | \begin{prog} |
611 | @<type>_0 $m$($C$ *me, @<type>_1 @<arg>_1, $\ldots$, | |
020b9e2b | 612 | @<type>_n @<arg>_n, \dots); \\ |
62f9852b MW |
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 | ||
0a2d4b68 | 617 | |
b8101b23 | 618 | \subsection{Additional definitions} \label{sec:structures.layout.additional} |
62f9852b MW |
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 | ||
43073476 MW |
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. | |
62f9852b MW |
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} | |
020b9e2b | 651 | extern const struct $R$__ilayout $C$__classobj; \\ |
489173a5 MW |
652 | \#define $C$__class (\&$C$__classobj.$j$.$r$) \\ |
653 | \#define $C$__cls_$k$ (\&$C$__classobj.$k$.$n$) \\ | |
654 | \quad$\vdots$ | |
62f9852b MW |
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 | |
489173a5 MW |
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 | ||
62f9852b MW |
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: |