Subversion Repositories tendra.SVN

Rev

Rev 2 | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
2 7u83 1 
<!-- Crown Copyright (c) 1998 -->
2 
<HTML>
3 
<HEAD>
4 
<TITLE>
5 
C++ Producer Guide: Type system
6 
</TITLE>
7 
</HEAD>
8 
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
9 
 
10 
<H1>C++ Producer Guide</H1>
11 
<H3>March 1998</H3>
12 
<A HREF="error.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
13 
<A HREF="style.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
14 
<A HREF="index.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
15 
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
16 
</A>
17 
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
18 
<HR>
19 
 
20 
<DL>
21 
<DT><A HREF="#primitive"><B>3.2.1</B> - Primitive types</A><DD>
22 
<DT><A HREF="#cv"><B>3.2.2</B> - <CODE>CV_SPEC</CODE></A><DD>
23 
<DT><A HREF="#ntype"><B>3.2.3</B> - <CODE>BUILTIN_TYPE</CODE></A><DD>
24 
<DT><A HREF="#btype"><B>3.2.4</B> - <CODE>BASE_TYPE</CODE></A><DD>
25 
<DT><A HREF="#itype"><B>3.2.5</B> - <CODE>INT_TYPE</CODE></A><DD>
26 
<DT><A HREF="#ftype"><B>3.2.6</B> - <CODE>FLOAT_TYPE</CODE></A><DD>
27 
<DT><A HREF="#cinfo"><B>3.2.7</B> - <CODE>CLASS_INFO</CODE></A><DD>
28 
<DT><A HREF="#cusage"><B>3.2.8</B> - <CODE>CLASS_USAGE</CODE></A><DD>
29 
<DT><A HREF="#ctype"><B>3.2.9</B> - <CODE>CLASS_TYPE</CODE></A><DD>
30 
<DT><A HREF="#graph"><B>3.2.10</B> - <CODE>GRAPH</CODE></A><DD>
31 
<DT><A HREF="#virt"><B>3.2.11</B> - <CODE>VIRTUAL</CODE></A><DD>
32 
<DT><A HREF="#etype"><B>3.2.12</B> - <CODE>ENUM_TYPE</CODE></A><DD>
33 
<DT><A HREF="#type"><B>3.2.13</B> - <CODE>TYPE</CODE></A><DD>
34 
<DT><A HREF="#dspec"><B>3.2.14</B> - <CODE>DECL_SPEC</CODE></A><DD>
35 
<DT><A HREF="#hashid"><B>3.2.15</B> - <CODE>HASHID</CODE></A><DD>
36 
<DT><A HREF="#qual"><B>3.2.16</B> - <CODE>QUALIFIER</CODE></A><DD>
37 
<DT><A HREF="#id"><B>3.2.17</B> - <CODE>IDENTIFIER</CODE></A><DD>
38 
<DT><A HREF="#member"><B>3.2.18</B> - <CODE>MEMBER</CODE></A><DD>
39 
<DT><A HREF="#nspace"><B>3.2.19</B> - <CODE>NAMESPACE</CODE></A><DD>
40 
<DT><A HREF="#nat"><B>3.2.20</B> - <CODE>NAT</CODE></A><DD>
41 
<DT><A HREF="#flt"><B>3.2.21</B> - <CODE>FLOAT</CODE></A><DD>
42 
<DT><A HREF="#str"><B>3.2.22</B> - <CODE>STRING</CODE></A><DD>
43 
<DT><A HREF="#ntest"><B>3.2.23</B> - <CODE>NTEST</CODE></A><DD>
44 
<DT><A HREF="#rmode"><B>3.2.24</B> - <CODE>RMODE</CODE></A><DD>
45 
<DT><A HREF="#exp"><B>3.2.25</B> - <CODE>EXP</CODE></A><DD>
46 
<DT><A HREF="#off"><B>3.2.26</B> - <CODE>OFFSET</CODE></A><DD>
47 
<DT><A HREF="#tok"><B>3.2.27</B> - <CODE>TOKEN</CODE></A><DD>
48 
<DT><A HREF="#inst"><B>3.2.28</B> - <CODE>INSTANCE</CODE></A><DD>
49 
<DT><A HREF="#err"><B>3.2.29</B> - <CODE>ERROR</CODE></A><DD>
50 
<DT><A HREF="#var"><B>3.2.30</B> - <CODE>VARIABLE</CODE></A><DD>
51 
<DT><A HREF="#loc"><B>3.2.31</B> - <CODE>LOCATION</CODE></A><DD>
52 
<DT><A HREF="#posn"><B>3.2.32</B> - <CODE>POSITION</CODE></A><DD>
53 
<DT><A HREF="#bits"><B>3.2.33</B> - <CODE>BITSTREAM</CODE></A><DD>
54 
<DT><A HREF="#buff"><B>3.2.34</B> - <CODE>BUFFER</CODE></A><DD>
55 
<DT><A HREF="#opt"><B>3.2.35</B> - <CODE>OPTIONS</CODE></A><DD>
56 
<DT><A HREF="#pptok"><B>3.2.36</B> - <CODE>PPTOKEN</CODE></A><DD>
57 
</DL>
58 
<HR>
59 
 
60 
<H2>3.2. Type system</H2>
61 
<P>
62 
This section describes the type system used in the C++ producer. Unless
63 
otherwise stated the types are declared using the
64 
<A HREF="../utilities/calc.html"><CODE>calculus</CODE> tool</A> as
65 
part of the algebra, <CODE>c_class.alg</CODE>.  The design of this
66 
type algebra was clearly largely based on the concepts underlying
67 
the C++ language; however TDF provided an important influence, not
68 
merely as the intended target language, but also because of its clear
69 
presentation of essential language features.
70 
</P>
71 
 
72 
<HR>
73 
<H3><A NAME="primitive">3.2.1. Primitive types</A></H3>
74 
<P>
75 
The primitive types used within the algebra <CODE>c_class</CODE> are
76 
defined as follows:
77 
<PRE>
78 
	int = &quot;int&quot; ;
79 
	unsigned = &quot;unsigned&quot; ;
80 
	string = &quot;character *&quot; ;
81 
	ulong_type (ulong) = &quot;unsigned long&quot; ;
82 
	BITSTREAM_P (bits) = &quot;BITSTREAM *&quot; ;
83 
	PPTOKEN_P (pptok) = &quot;PPTOKEN *&quot; ;
84 
</PRE>
85 
The integral types are self-explanatory.  All string literals used
86 
in the C++ producer are based on the character type:
87 
<PRE>
88 
	typedef unsigned char character ;
89 
</PRE>
90 
hence the definition of <CODE>string</CODE>.  The remaining primitive
91 
give links to those portions of the type system which are defined
92 
outside of the algebra.  The types <A HREF="#bits"><CODE>BITSTREAM</CODE></A>
93 
and <A HREF="#pptok"><CODE>PPTOKEN</CODE></A> are described below.
94 
</P>
95 
 
96 
<HR>
97 
<H3><A NAME="cv">3.2.2. <CODE>CV_SPEC</CODE></A></H3>
98 
<P>
99 
The enumeration type <CODE>CV_SPEC</CODE> (short name <CODE>cv</CODE>)
100 
is used to represent a C++ type qualifier.  It takes the form of a
101 
bitfield, the elements of which can be or-ed together to represent
102 
combinations of type qualifiers.  The cv-qualifiers are represented
103 
by <CODE>cv_const</CODE> and <CODE>cv_volatile</CODE> in the obvious
104 
manner.  The value <CODE>cv_lvalue</CODE> is used as a qualifier to
105 
indicate whether a type is an lvalue or an rvalue.  Other values are
106 
used in function types to represent the function language linkage.
107 
</P>
108 
 
109 
<HR>
110 
<H3><A NAME="ntype">3.2.3. <CODE>BUILTIN_TYPE</CODE></A></H3>
111 
<P>
112 
The enumeration type <CODE>BUILTIN_TYPE</CODE> (<CODE>ntype</CODE>)
113 
is used to represent the built-in C++ types (<CODE>char</CODE>,
114 
<CODE>float</CODE>, <CODE>void</CODE> etc.).  It is used chiefly as
115 
an index into tables of type information.
116 
</P>
117 
 
118 
<HR>
119 
<H3><A NAME="btype">3.2.4. <CODE>BASE_TYPE</CODE></A></H3>
120 
<P>
121 
The enumeration type <CODE>BASE_TYPE</CODE> (<CODE>btype</CODE>) is
122 
used to represent a C++ simple type specifier such as <CODE>signed</CODE>,
123 
<CODE>short</CODE> or <CODE>int</CODE>.  It takes the form of a bitfield,
124 
the elements of which can be or-ed together to represent combinations
125 
of type specifiers.  Its chief use is when reading a type from the
126 
input file; the various simple type specifiers are combined to give
127 
a value of this type, which is then mapped to an actual <A HREF="#type">C++
128 
type</A>.
129 
</P>
130 
 
131 
<HR>
132 
<H3><A NAME="itype">3.2.5. <CODE>INT_TYPE</CODE></A></H3>
133 
<P>
134 
The union type <CODE>INT_TYPE</CODE> (<CODE>itype</CODE>) is used
135 
to represent an integral or bitfield C++ type.  The basic integral
136 
types are given by the <CODE>basic</CODE> field.  Bitfield types are
137 
represented by the <CODE>bitfield</CODE> field.  There are also fields
138 
representing target dependent integral promotion, arithmetic and integer
139 
literal types, plus <CODE>VARIETY</CODE> tokens.  Only one <CODE>INT_TYPE</CODE>
140 
object is created for each integral type.
141 
</P>
142 
 
143 
<HR>
144 
<H3><A NAME="ftype">3.2.6. <CODE>FLOAT_TYPE</CODE></A></H3>
145 
<P>
146 
The union type <CODE>FLOAT_TYPE</CODE> (<CODE>ftype</CODE>) is used
147 
to represent a floating point C++ type.  The basic floating point
148 
types are given by the <CODE>basic</CODE> field.  There are also fields
149 
representing target dependent argument promotion and arithmetic types,
150 
plus <CODE>FLOAT</CODE> tokens.  Only one <CODE>FLOAT_TYPE</CODE>
151 
object is created for each floating point type.
152 
</P>
153 
 
154 
<HR>
155 
<H3><A NAME="cinfo">3.2.7. <CODE>CLASS_INFO</CODE></A></H3>
156 
<P>
157 
The enumeration type <CODE>CLASS_INFO</CODE> (<CODE>cinfo</CODE>)
158 
is used to represent information relating to a class or enumeration
159 
definition.  It takes the form of a bitfield, the elements of which
160 
can be or-ed together to represent various combinations of properties.
161 
</P>
162 
 
163 
<HR>
164 
<H3><A NAME="cusage">3.2.8. <CODE>CLASS_USAGE</CODE></A></H3>
165 
<P>
166 
The enumeration type <CODE>CLASS_USAGE</CODE> (<CODE>cusage</CODE>)
167 
is used to represent information relating to the way a class is used.
168 
It takes the form of a bitfield, the elements of which can be or-ed
169 
together to represent various combinations of properties.
170 
</P>
171 
 
172 
<HR>
173 
<H3><A NAME="ctype">3.2.9. <CODE>CLASS_TYPE</CODE></A></H3>
174 
<P>
175 
The union type <CODE>CLASS_TYPE</CODE> (<CODE>ctype</CODE>) is used
176 
to represent a C++ class or union.  The main components are an
177 
<A HREF="#id">identifier</A> giving the class name,
178 
<A HREF="#cinfo">class information</A> and <A HREF="#cusage">class
179 
usage</A> fields, a <A HREF="#nspace">namespace</A> giving the class
180 
members, a <A HREF="#graph">graph</A> representing the base class
181 
structure, and a <A HREF="#virt">virtual function table</A>.  Only
182 
one
183 
<CODE>CLASS_TYPE</CODE> object is created for each class or union.
184 
</P>
185 
<P>
186 
Each class maintains a list, <CODE>pals</CODE>, of class and function
187 
identifiers which are declared as friends of that class.  It also
188 
maintains a list, <CODE>chums</CODE>, of those class types which declare
189 
it to be a friend (this is what is actually used in the access checks).
190 
Similarly each function identifier maintains a list,
191 
<CODE>chums</CODE>, of those class types which declare it to be a
192 
friend.
193 
</P>
194 
<P>
195 
Each class maintains a list of its constructors, destructors and conversion
196 
functions (included inherited conversion functions).  It also maintains
197 
a list of its virtual base classes.  This information can be obtained
198 
by other means but it is more convenient to record it within the class
199 
type itself.
200 
</P>
201 
 
202 
<HR>
203 
<H3><A NAME="graph">3.2.10. <CODE>GRAPH</CODE></A></H3>
204 
<P>
205 
The union type <CODE>GRAPH</CODE> (<CODE>graph</CODE>) is used to
206 
represent a directed acyclic graph arising from the base classes of
207 
a class.  Each node of the graph has a <CODE>head</CODE> which is
208 
a
209 
<A HREF="#ctype">class type</A>, and several <CODE>tails</CODE> which
210 
give the base class graphs for that class.  Each node has pointers,
211 
<CODE>top</CODE>, to the top of the graph (i.e. the most derived class),
212 
and <CODE>up</CODE>, to the node of which the current node is a direct
213 
base.  Each node also has an <CODE>access</CODE> field which gives
214 
information on the base access, whether it is virtual or not, and
215 
so on, in the form of a <A HREF="#dspec"><CODE>DECL_SPEC</CODE></A>.
216 
Virtual bases are handled by the <CODE>equal</CODE> field which defines
217 
an equivalence relation on the graph which identifies equivalent virtual
218 
bases.
219 
</P>
220 
 
221 
<HR>
222 
<H3><A NAME="virt">3.2.11. <CODE>VIRTUAL</CODE></A></H3>
223 
<P>
224 
The union type <CODE>VIRTUAL</CODE> (<CODE>virt</CODE>) is used to
225 
represent the virtual functions declared in a class.  The <CODE>table</CODE>
226 
field is used to represent a virtual function table, and consists
227 
primarily of a list of <CODE>VIRTUAL</CODE> objects giving the virtual
228 
functions for the associated class.  These virtual functions are of
229 
four kinds, each represented by a union field.  A virtual function
230 
first declared in a class is represented by the <CODE>simple</CODE>
231 
field; a virtual function in a class which overrides an inherited
232 
virtual function is represented by the <CODE>override</CODE> field;
233 
an inherited, non-overridden virtual function which is not overridden
234 
in a base class is represented by the
235 
<CODE>inherit</CODE> field; a inherited, non-overridden virtual function
236 
which is overridden in some base class is represented by the
237 
<CODE>complex</CODE> field.
238 
</P>
239 
 
240 
<HR>
241 
<H3><A NAME="etype">3.2.12. <CODE>ENUM_TYPE</CODE></A></H3>
242 
<P>
243 
The union type <CODE>ENUM_TYPE</CODE> (<CODE>etype</CODE>) is used
244 
to represent a C++ enumeration type.  This consists primarily of an
245 
<A HREF="#id">identifier</A> giving the enumeration name, a
246 
<A HREF="#cinfo">class information</A> field, a <A HREF="#type">type</A>
247 
giving the underlying representation of the enumeration type, and
248 
a list of <A HREF="#id">identifiers</A> giving the enumerators comprising
249 
the enumeration.
250 
</P>
251 
 
252 
<HR>
253 
<H3><A NAME="type">3.2.13. <CODE>TYPE</CODE></A></H3>
254 
<P>
255 
The union type <CODE>TYPE</CODE> (<CODE>type</CODE>) is used to represent
256 
a C++ type.  Every type has an associated <A HREF="#cv">type qualifier</A>,
257 
<CODE>qual</CODE>, which determines whether the type is
258 
<CODE>const</CODE>, <CODE>volatile</CODE> or an lvalue.  A type may
259 
also have an associated <A HREF="#id">identifier</A>, <CODE>name</CODE>,
260 
giving the corresponding type name (the null identifier being used
261 
for unnamed types).  The other type components are determined by the
262 
union tag.  Each of the type constructs above has a corresponding
263 
field in the <CODE>TYPE</CODE> union:
264 
<CODE>integer</CODE> for <A HREF="#itype">integral types</A>,
265 
<CODE>floating</CODE> for <A HREF="#ftype">floating point types</A>,
266 
<CODE>bitfield</CODE> for <A HREF="#itype">bitfield types</A>,
267 
<CODE>compound</CODE> for <A HREF="#ctype">class or union types</A>,
268 
and
269 
<CODE>enumerate</CODE> for <A HREF="#etype">enumeration types</A>.
270 
There are also fields <CODE>top</CODE> and <CODE>bottom</CODE>
271 
corresponding to <CODE>void</CODE> and bottom (the type used to represent
272 
values which never return).
273 
</P>
274 
<P>
275 
Other fields of the <CODE>TYPE</CODE> union represent composite types;
276 
for example, the <CODE>array</CODE> field, representing array types,
277 
comprises a base type, <CODE>sub</CODE>, and an <A HREF="#nat">integer
278 
constant</A> giving the array bound, <CODE>size</CODE>.  These are
279 
generally simple, apart from <CODE>func</CODE>, representing a function
280 
type.  This has the obvious components: a return type, <CODE>ret</CODE>,
281 
a list of parameter types, <CODE>ptypes</CODE>, and a flag indicating
282 
ellipsis functions, <CODE>ellipsis</CODE>.  It also has an associated
283 
<A HREF="#nspace">namespace</A>, <CODE>pars</CODE>, in which the function
284 
parameters are declared.  The parameter identifiers are extracted
285 
from this as a list, <CODE>pids</CODE>.  Member function qualifiers
286 
and language linkage information are represented by a
287 
<A HREF="#cv"><CODE>CV_QUAL</CODE></A>, <CODE>mqual</CODE>.  The implicit
288 
extra parameter for member functions is recorded in the list
289 
<CODE>mtypes</CODE>, which adds this extra type to the start of
290 
<CODE>ptypes</CODE>.  Finally <CODE>except</CODE> gives any exception
291 
specifiers; the case where the exception specifier is absent being
292 
represented by the special value, <CODE>univ_type_set</CODE>.
293 
</P>
294 
 
295 
<HR>
296 
<H3><A NAME="dspec">3.2.14. <CODE>DECL_SPEC</CODE></A></H3>
297 
<P>
298 
The enumeration type <CODE>DECL_SPEC</CODE> (<CODE>dspec</CODE>) is
299 
used to represent information on the declaration and usage of an identifier.
300 
It takes the form of a bitfield, the elements of which can be or-ed
301 
together to represent various combinations of properties.  The 32
302 
bits in this bitfield (the maximum which can be represented portably)
303 
are a significant restriction.  This means that the same member of
304 
<CODE>DECL_SPEC</CODE> is often used to mean different things in different
305 
contexts.  This can prove confusing on occasions.
306 
</P>
307 
 
308 
<HR>
309 
<H3><A NAME="hashid">3.2.15. <CODE>HASHID</CODE></A></H3>
310 
<P>
311 
The union type <CODE>HASHID</CODE> (<CODE>hashid</CODE>) is used to
312 
represent a C++ identifier name.  The simplest form of identifier
313 
name,
314 
<CODE>name</CODE>, consists of just a string of characters, such as
315 
<CODE>foo</CODE>.  Extended identifier names, <CODE>ename</CODE>,
316 
are similar, but may contain Unicode characters.  There are however
317 
other forms of identifier name in C++: conversion function names (<CODE>conv
318 
</CODE>) such as <CODE>operator int</CODE>, overloaded operator names
319 
(<CODE>op</CODE>) such as <CODE>operator+</CODE>, constructor names
320 
(<CODE>constr</CODE>), and destructor names (<CODE>destr</CODE>).
321 
There are also names which are used for anonymous identifiers (<CODE>anon</CODE>).
322 
</P>
323 
<P>
324 
Note the distinction between an identifier name and an actual
325 
<A HREF="#id">identifier</A>.  The latter is a meaning associated
326 
with a name in a particular context.  Every identifier name has an
327 
associated underlying meaning, <CODE>id</CODE>.  This is used to handle
328 
keywords and macros, but for most identifier names this will be a
329 
dummy identifier. Nested underlying meanings (such as a macro hiding
330 
a keyword) are handled by linking the <CODE>alias</CODE> fields of
331 
the corresponding identifiers.  Every identifier name also has a <CODE>cache
332 
</CODE> field which is used to record the look-up of this name as
333 
an unqualified identifier.  This may be set to the null identifier
334 
to indicate that the look-up needs to be re-evaluated.
335 
</P>
336 
<P>
337 
Identifier names are stored in one of a small number of hash tables,
338 
linked using their <CODE>next</CODE> field.  Each name has only one
339 
entry in these tables, allowing equality of names to be implemented
340 
as <CODE>EQ_hashid</CODE>.
341 
</P>
342 
 
343 
<HR>
344 
<H3><A NAME="qual">3.2.16. <CODE>QUALIFIER</CODE></A></H3>
345 
<P>
346 
The enumeration type <CODE>QUALIFIER</CODE> (<CODE>qual</CODE>) is
347 
used to represent the various ways in which an identifier name can
348 
be qualified.  For example, <CODE>::A::a</CODE> is represented by
349 
<CODE>qual_full</CODE>.  The value <CODE>qual_mark</CODE> is used
350 
in the representation of function identifier expressions to indicate
351 
that overload resolution has been performed.
352 
</P>
353 
 
354 
<HR>
355 
<H3><A NAME="id">3.2.17. <CODE>IDENTIFIER</CODE></A></H3>
356 
<P>
357 
The union type <CODE>IDENTIFIER</CODE> (<CODE>id</CODE>) is used to
358 
represent the various kinds of C++ identifiers.  Every identifier
359 
has an associated <A HREF="#hashid">identifier name</A>, a parent
360 
<A HREF="#nspace">namespace</A>, a <A HREF="#dspec">declaration information</A>
361 
field, and a <A HREF="#loc">location</A> for its declaration or definition.
362 
Each identifier also has an
363 
<CODE>alias</CODE> field which is normally used to represent the aliasing
364 
which can occur in inheritance or <CODE>using</CODE>
365 
declarations.
366 
</P>
367 
<P>
368 
The various fields of the <CODE>IDENTIFIER</CODE> union correspond
369 
to the various kinds of identifier which can arise in C++ - class
370 
names, functions, variables, class members, macros, keywords etc.
371 
Each field has appropriate components giving its type, its definition
372 
or whatever other information is required.  For example, the <CODE>variable
373 
</CODE>
374 
field has a <A HREF="#type">type</A> and two <A HREF="#exp">expressions</A>,
375 
giving the constructor and destructor values for the object.
376 
</P>
377 
<P>
378 
Most of these identifier components are self-explanatory, however
379 
the treatment of overloaded functions bears discussion.  The various
380 
fields representing functions have an <CODE>over</CODE> component
381 
which is used to link overloaded functions together.  A set of overloaded
382 
functions is treated as if it were a single <CODE>IDENTIFIER</CODE>
383 
- the first in the list - for the purposes of storing in a <A HREF="#member">namespace
384 
member</A>; the other overloaded meanings are accessed by chasing
385 
down the <CODE>over</CODE> components.  In other situations, whether
386 
a function identifier represents a single function or a set of overloaded
387 
functions can be worked out from the context.  For example, in identifier
388 
expressions the <A HREF="#qual">identifier qualifier</A> is used to
389 
mark whether overload resolution has taken place.
390 
</P>
391 
 
392 
<HR>
393 
<H3><A NAME="member">3.2.18. <CODE>MEMBER</CODE></A></H3>
394 
<P>
395 
The union type <CODE>MEMBER</CODE> (<CODE>member</CODE>) is used to
396 
represent a member of a <A HREF="#nspace">namespace</A>.  Each member
397 
contains two identifiers, <CODE>id</CODE> and <CODE>alt</CODE>.  The
398 
<CODE>id</CODE> field gives the meaning associated with a particular
399 
name in this namespace; the <CODE>alt</CODE> field is used to represent
400 
a type name which may be hidden by a non-type name.
401 
</P>
402 
<P>
403 
There are two kinds of member, <CODE>small</CODE> and <CODE>large</CODE>,
404 
corresponding to whether the namespace holds its members in a simple
405 
linked list or in a hash table.
406 
</P>
407 
 
408 
<HR>
409 
<H3><A NAME="nspace">3.2.19. <CODE>NAMESPACE</CODE></A></H3>
410 
<P>
411 
The union type <CODE>NAMESPACE</CODE> (<CODE>nspace</CODE>) is used
412 
to represent the set of identifiers declared in a particular scope.
413 
For example, the members declared in a C++ class or namespace, the
414 
parameters declared in a function declarator and the local variables
415 
declared in a block all form scopes.  The various kinds of scope are
416 
distinguished as different fields of the union, but there are basically
417 
two categories.  The first, such as function blocks, which have relatively
418 
small numbers of elements, store their members as a simple linked
419 
lists.  The second, such as classes, which have larger numbers of
420 
elements, store their members in hash tables.  In both cases the elements
421 
are stored using the <A HREF="#member"><CODE>MEMBER</CODE></A>
422 
type.
423 
</P>
424 
<P>
425 
The key operation on a namespace is to look up a particular
426 
<A HREF="#hashid">identifier name</A> in its linked list or hash table
427 
of members to find the meaning, if any, associated with that name
428 
in the namespace.  This can be a complex operation because of the
429 
need to take base classes and <CODE>using</CODE> directives (as stored
430 
in the <CODE>use</CODE> component) into account.
431 
</P>
432 
 
433 
<HR>
434 
<H3><A NAME="nat">3.2.20. <CODE>NAT</CODE></A></H3>
435 
<P>
436 
The union type <CODE>NAT</CODE> (<CODE>nat</CODE>) is used to represent
437 
an integer constant expression.  Values are represented as lists of
438 
16 bit 'digits'.  Values which fit into a single digit are represented
439 
by the <CODE>small</CODE> field; larger values by the <CODE>large</CODE>
440 
field.  Negated values can be represented by the <CODE>neg</CODE>
441 
field. Folding of integer constant expressions is performed in the
442 
producer, however the result can only be represented as described
443 
above if its value is target independent.  Target dependent values
444 
are represented by the <CODE>calc</CODE> field which contains an
445 
<A HREF="#exp">expression</A> describing how to calculate the value.
446 
The <CODE>token</CODE> field is used to represent <CODE>NAT</CODE>
447 
tokens.
448 
</P>
449 
<P>
450 
Objects representing small integer constants are created at the start
451 
of the program and stored in a table for ease of access.  Larger constants
452 
are created as and when they are required.
453 
</P>
454 
 
455 
<HR>
456 
<H3><A NAME="flt">3.2.21. <CODE>FLOAT</CODE></A></H3>
457 
<P>
458 
The union type <CODE>FLOAT</CODE> (<CODE>flt</CODE>) is used to represent
459 
a floating point constant expression.  There is only one field, <CODE>simple
460 
</CODE>, which corresponds to a floating point literal.  No folding
461 
of floating point constant expressions is attempted in the producer
462 
(it is virtually impossible to do so in a target independent manner).
463 
</P>
464 
<P>
465 
Objects representing useful floating point constants (0.0, 1.0 etc.)
466 
are created for each floating point type and stored as part of the
467 
corresponding <A HREF="#ftype"><CODE>FLOAT_TYPE</CODE></A>.  Other
468 
values are created as and when they are required.
469 
</P>
470 
 
471 
<HR>
472 
<H3><A NAME="str">3.2.22. <CODE>STRING</CODE></A></H3>
473 
<P>
474 
The union type <CODE>STRING</CODE> (<CODE>str</CODE>) is used to represent
475 
a string constant expression.  There is only one field,
476 
<CODE>simple</CODE>, which corresponds to a character string literal,
477 
however the <CODE>kind</CODE> field can be used to modify the interpretation
478 
put on the characters appearing in the <CODE>text</CODE>
479 
field.  By default, each character in <CODE>text</CODE> corresponds
480 
to a single character in the literal; however an alternative representation,
481 
in which <CODE>text</CODE> consists of a sequence of multibyte characters
482 
- one control character plus four value characters - is used in more
483 
complex cases.
484 
</P>
485 
<P>
486 
All strings are stored in a hash table intended to ensure that the
487 
same <CODE>STRING</CODE> object is used for equal string literals.
488 
This not only saves space during the processing of the input file,
489 
but also facilitates the output of shared string literals in the TDF
490 
capsule.
491 
</P>
492 
<P>
493 
Note that the terminal zero character does not form part of the
494 
<CODE>STRING</CODE> object.  Instead information on this is stored
495 
as part of the type of a <A HREF="#exp">string literal expression</A>.
496 
The text of the string literal is either truncated or padded with
497 
zeros until its length matches the size of the array bound in the
498 
type of the corresponding literal expression.
499 
</P>
500 
 
501 
<HR>
502 
<H3><A NAME="ntest">3.2.23. <CODE>NTEST</CODE></A></H3>
503 
<P>
504 
The enumeration type <CODE>NTEST</CODE> (<CODE>ntest</CODE>) is used
505 
to represent the various C++ relational operators (<CODE>==</CODE>,
506 
<CODE>!=</CODE>, <CODE>&gt;</CODE> etc.).  The values correspond to
507 
the encoding of the TDF <CODE>NTEST</CODE> sort, which facilitates
508 
code generation.  The values also have the property that the values
509 
for complementary operators (such as <CODE>&lt;</CODE> and
510 
<CODE>&gt;=</CODE>) always add up to the same value,
511 
<CODE>ntest_negate</CODE>, allowing operators to be complemented in
512 
a straightforward manner.
513 
</P>
514 
 
515 
<HR>
516 
<H3><A NAME="rmode">3.2.24. <CODE>RMODE</CODE></A></H3>
517 
<P>
518 
The enumeration type <CODE>RMODE</CODE> (<CODE>rmode</CODE>) is used
519 
to represent the various C++ rounding modes (towards zero, towards
520 
smaller etc.).  The values correspond to the encoding of the TDF
521 
<CODE>RMODE</CODE> sort, which facilitates code generation.
522 
</P>
523 
 
524 
<HR>
525 
<H3><A NAME="exp">3.2.25. <CODE>EXP</CODE></A></H3>
526 
<P>
527 
The union type <CODE>EXP</CODE> (<CODE>exp</CODE>) is used to represent
528 
a C++ expression or statement.  Each expression has an associated
529 
<A HREF="#type">type</A>, <CODE>type</CODE>, but most of the information
530 
about an expression is stored in one of the large number of fields
531 
of the <CODE>EXP</CODE> union.  Most of these fields are fairly simple.
532 
For example, there are fields corresponding to <A HREF="#nat">integer
533 
literals</A>, <A HREF="#flt">floating point literals</A>,
534 
<A HREF="#str">string literals</A> and <A HREF="#id">identifiers</A>.
535 
Composite expressions are formed in the normal way; for example, there
536 
are various binary operators comprising two argument expressions.
537 
The
538 
<CODE>EXP</CODE> fields corresponding to statements are slightly more
539 
complex.  They each have a <CODE>parent</CODE> field which points
540 
to the enclosing statement.  A couple of cases bear additional discussion.
541 
</P>
542 
<P>
543 
The <CODE>sequence</CODE> field represents a compound statement or
544 
block.  This contains a <A HREF="#nspace">namespace</A>, in which
545 
any local variables are declared, and a list of expressions, giving
546 
the statements comprising the block.  The null namespace is used if
547 
the block does not constitute a scope.  The first statement in the
548 
list is always a dummy to enable <CODE>first</CODE> and <CODE>last</CODE>
549 
pointers to be maintained to the start and end of the list without
550 
having to worry about null lists.
551 
</P>
552 
<P>
553 
<A NAME="solve">The <CODE>solve_stmt</CODE> field corresponds to the
554 
TDF <CODE>labelled</CODE> construct</A> (in early versions of TDF
555 
this construct was called <CODE>solve</CODE>, hence the terminology).
556 
The problem is that C and C++ labels and <CODE>goto</CODE>s are totally
557 
unstructured, whereas the TDF label constructs are structured.  Any
558 
statement which contains unstructured labels is enclosed in a
559 
<CODE>solve_stmt</CODE> construct, enclosing both the labelled statement
560 
and all jumps to it (in general this cannot be done until the end
561 
of the function).  Any labels or variables which are bypassed by such
562 
unstructured jumps also need to be pulled out to the <CODE>solve_stmt</CODE>
563 
construct.  It is not just explicit labels which can cause such problems;
564 
complex <CODE>switch</CODE> statements have the same effect.
565 
</P>
566 
 
567 
<HR>
568 
<H3><A NAME="off">3.2.26. <CODE>OFFSET</CODE></A></H3>
569 
<P>
570 
The union type <CODE>OFFSET</CODE> (<CODE>off</CODE>) is used to represent
571 
an offset expression.  This is used as an adjunct to the normal
572 
<A HREF="#exp">expression</A> representation.  The <CODE>OFFSET</CODE>
573 
union has fields corresponding to a type offset (used in pointer arithmetic),
574 
the offset of a member of a class and the offset of a base class.
575 
There are also simple operations on offsets, such as multiplication
576 
by an expression.
577 
</P>
578 
 
579 
<HR>
580 
<H3><A NAME="tok">3.2.27. <CODE>TOKEN</CODE></A></H3>
581 
<P>
582 
The union type <CODE>TOKEN</CODE> (<CODE>tok</CODE>) is used to represent
583 
one of a number of different categories within the C++ language.
584 
It corresponds to the sort of a token declared using the
585 
<A HREF="token.html"><CODE>#pragma token</CODE> syntax</A>.  Thus
586 
there are fields corresponding to expression, statement, integer constant,
587 
type, function, member and procedure tokens.  The similarities between
588 
<CODE>PROC</CODE> tokens and templates have been remarked above; for
589 
example, the parameters of the template:
590 
<PRE>
591 
	template &lt; class T, int n &gt class A {
592 
	    T a [n] ;
593 
	    // ....
594 
	} ;
595 
</PRE>
596 
are essentially equivalent to those in the procedure token:
597 
<PRE>
598 
	PROC ( TYPE T, EXP const : int : n ) ....
599 
</PRE>
600 
(recall that non-type template arguments are always constant expressions).
601 
Thus a field, <CODE>templ</CODE>, of the <CODE>TOKEN</CODE> union
602 
is used to represent lists of template parameters.  Note that a further
603 
field, <CODE>class</CODE>, is also required to represent template
604 
template parameters.  A <A HREF="#type">template type</A> is represented
605 
by a field, <CODE>templ</CODE>, of the union <CODE>TYPE</CODE>, which
606 
comprises a template sort and a sub-type expressed in terms of the
607 
template parameters.
608 
</P>
609 
<P>
610 
In addition to representing token and template sorts in this way,
611 
the
612 
<CODE>TOKEN</CODE> union is used to represent token and template arguments.
613 
Each of the parameter sorts listed above has an appropriate
614 
<CODE>value</CODE> component which can store a value of that sort.
615 
Many of the union types in the algebra, including <A HREF="#type">types</A>
616 
and <A HREF="#exp">expressions</A>, have a field of the form:
617 
<PRE>
618 
	token -&gt; {
619 
	    IDENTIFIER tok ;
620 
	    LIST TOKEN args ;
621 
	}
622 
</PRE>
623 
representing the given token <A HREF="#id">identifier</A> applied
624 
to the given list of arguments.
625 
</P>
626 
<P>
627 
<A NAME="form">Template instances are represented slightly differently
628 
from token applications</A>.  Each instance of a template class or
629 
a template function gives rise to a new class or function
630 
<A HREF="#id">identifier</A>.  This identifier has an underlying form
631 
giving the template identifier and the template arguments.  This is
632 
expressed as a <CODE>token</CODE> member of the
633 
<A HREF="#type"><CODE>TYPE</CODE></A> union (although it is not technically
634 
a type, this happens to be the most convenient representation).  Each
635 
such form has an associated
636 
<A HREF="#inst"><CODE>INSTANCE</CODE></A> component which gives further
637 
information about the template instance.  The form for a template
638 
function instance is stored in the <CODE>form</CODE> component of
639 
the corresponding <A HREF="#id">identifier</A>.  The form for a template
640 
class instance is stored in the <CODE>form</CODE> component of the
641 
corresponding <A HREF="#ctype">class type</A>.
642 
</P>
643 
<P>
644 
Members of instances of template classes also have a form type, but
645 
in this case the form is an <CODE>instance</CODE> type.  This gives
646 
a link back to the corresponding member of the template class.
647 
</P>
648 
 
649 
<HR>
650 
<H3><A NAME="inst">3.2.28. <CODE>INSTANCE</CODE></A></H3>
651 
<P>
652 
The union type <CODE>INSTANCE</CODE> (<CODE>inst</CODE>) is used to
653 
represent a particular instance of a template or token.  Each
654 
<A HREF="#tok">template sort</A> has an associated list of all the
655 
instances of that template, which is used to ensure that the same
656 
template applied with the same arguments always has the same value.
657 
Information on partial or explicit specialisations and usage information
658 
are stored as part of the corresponding
659 
<CODE>INSTANCE</CODE>.  Each template instance identifier has a link
660 
back to its corresponding <CODE>INSTANCE</CODE> via its
661 
<A HREF="#form"><CODE>form</CODE> component</A>.
662 
</P>
663 
 
664 
<HR>
665 
<H3><A NAME="err">3.2.29. <CODE>ERROR</CODE></A></H3>
666 
<P>
667 
The union type <CODE>ERROR</CODE> (<CODE>err</CODE>) is used to represent
668 
an error arising during the compilation of a C++ program. Errors are
669 
first class objects within the producer and can be passed to and from
670 
procedures.  Each error has an associated <CODE>severity</CODE>
671 
(serious, warning, none etc.).  Simple errors are represented by the
672 
<CODE>simple</CODE> field, which consists of an index, <CODE>number</CODE>,
673 
into the error catalogue, plus a variable length list of error arguments.
674 
Errors can be combined into composite errors using the
675 
<CODE>compound</CODE> field, which represents the join of two errors
676 
-
677 
<CODE>head</CODE> followed by <CODE>tail</CODE>.
678 
</P>
679 
<P>
680 
The chief operation on an error after it has been built up is to report
681 
it.  Each error report consists of an error object and a
682 
<A HREF="#loc">file location</A> indicating where the error occurred.
683 
</P>
684 
 
685 
<HR>
686 
<H3><A NAME="var">3.2.30. <CODE>VARIABLE</CODE></A></H3>
687 
<P>
688 
The structure type <CODE>VARIABLE</CODE> (<CODE>var</CODE>) is used
689 
to represent a variable state and is used in the variable analysis
690 
checks.
691 
</P>
692 
 
693 
<HR>
694 
<H3><A NAME="loc">3.2.31. <CODE>LOCATION</CODE></A></H3>
695 
<P>
696 
The structure type <CODE>LOCATION</CODE> (<CODE>loc</CODE>) is used
697 
to represent a location in an input file.  It comprises a pointer
698 
to an
699 
<A HREF="#posn">input file position</A>, <CODE>posn</CODE>, modified
700 
by a line number, taking <CODE>#line</CODE> directives into account,
701 
<CODE>line</CODE>.  Note that character positions within the line
702 
are not currently recorded.
703 
</P>
704 
 
705 
<HR>
706 
<H3><A NAME="posn">3.2.32. <CODE>POSITION</CODE></A></H3>
707 
<P>
708 
The structure type <CODE>POSITION</CODE> (<CODE>posn</CODE>) is used
709 
to represent a position in an input file.  It consists of two file
710 
names,
711 
<CODE>file</CODE> taking <CODE>#line</CODE> directives into account,
712 
and
713 
<CODE>input</CODE> giving the actual file name, plus a line number
714 
offset, <CODE>offset</CODE>, which gives the difference between the
715 
line number taking <CODE>#line</CODE> directives into account and
716 
the actual line number.  Other information stored includes the datestamp
717 
on the input file, <CODE>datestamp</CODE>, and a pointer to a
718 
<A HREF="#loc">file location</A> which, for files included using
719 
<CODE>#include</CODE>, gives the location the file was included from.
720 
</P>
721 
 
722 
<HR>
723 
<H3><A NAME="bits">3.2.33. <CODE>BITSTREAM</CODE></A></H3>
724 
<P>
725 
The structure <CODE>BITSTREAM</CODE> is not part of the
726 
<CODE>calculus</CODE> type system.  It is used to represent a sequence
727 
of bits such as is used, for example, in the encoding of TDF.
728 
</P>
729 
 
730 
<HR>
731 
<H3><A NAME="buff">3.2.34. <CODE>BUFFER</CODE></A></H3>
732 
<P>
733 
The structure <CODE>BUFFER</CODE> is not part of the <CODE>calculus</CODE>
734 
type system.  It is used to represent a sequence of characters.
735 
</P>
736 
 
737 
<HR>
738 
<H3><A NAME="opt">3.2.35. <CODE>OPTIONS</CODE></A></H3>
739 
<P>
740 
The structure <CODE>OPTIONS</CODE> is not part of the <CODE>calculus</CODE>
741 
type system.  It is used to represent the state of the
742 
<A HREF="pragma.html#low">compiler options</A> at a particular point
743 
in the input file.
744 
</P>
745 
 
746 
<HR>
747 
<H3><A NAME="pptok">3.2.36. <CODE>PPTOKEN</CODE></A></H3>
748 
<P>
749 
The structure <CODE>PPTOKEN</CODE> is not part of the <CODE>calculus</CODE>
750 
type system.  It is used to represent a linked list of preprocessing
751 
tokens.  Each token has an associated <CODE>sid</CODE> lexical token
752 
number, <CODE>tok</CODE>, plus additional data dependent on the token
753 
type.  Each token also records a pointer to the current
754 
<A HREF="#opt"><CODE>OPTIONS</CODE></A> value.
755 
</P>
756 
 
757 
<HR>
758 
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
759 
Copyright &copy; 1998.</I></P>
760 
</BODY>
761 
</HTML>