1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<TITLE>AARM95 - Access Types</TITLE>
<META NAME="Author" CONTENT="JTC1/SC22/WG9/ARG, by Randall Brukardt, ARG Editor">
<META NAME="GENERATOR" CONTENT="Arm_Form.Exe, Ada Reference Manual generator">
<STYLE type="text/css">
DIV.paranum {position: absolute; font-family: Arial, Helvetica, sans-serif; left: 0.5 em; top: auto}
TT {font-family: "Courier New", monospace}
DT {display: compact}
DIV.Normal {font-family: "Times New Roman", Times, serif; margin-bottom: 0.6em}
DIV.Wide {font-family: "Times New Roman", Times, serif; margin-top: 0.6em; margin-bottom: 0.6em}
DIV.Annotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
DIV.WideAnnotations {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0.6em; margin-bottom: 0.6em}
DIV.Index {font-family: "Times New Roman", Times, serif}
DIV.SyntaxSummary {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
DIV.Notes {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.6em}
DIV.NotesHeader {font-family: "Times New Roman", Times, serif; margin-left: 2.0em}
DIV.SyntaxIndented {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-bottom: 0.4em}
DIV.Indented {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-bottom: 0.6em}
DIV.CodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-bottom: 0.6em}
DIV.SmallIndented {font-family: "Times New Roman", Times, serif; margin-left: 10.0em; margin-bottom: 0.6em}
DIV.SmallCodeIndented {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-bottom: 0.6em}
DIV.Examples {font-family: "Courier New", monospace; margin-left: 2.0em; margin-bottom: 0.6em}
DIV.SmallExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left: 7.5em; margin-bottom: 0.6em}
DIV.IndentedExamples {font-family: "Courier New", monospace; margin-left: 8.0em; margin-bottom: 0.6em}
DIV.SmallIndentedExamples {font-family: "Courier New", monospace; font-size: 80%; margin-left: 15.0em; margin-bottom: 0.6em}
UL.Bulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SmallBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SmallNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.IndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.CodeIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.CodeIndentedNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-right: 8.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.SyntaxIndentedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NotesBulleted {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
UL.NotesNestedBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
DL.Hanging {font-family: "Times New Roman", Times, serif; margin-top: 0em; margin-bottom: 0.6em}
DD.Hanging {margin-left: 6.0em}
DL.IndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.IndentedHanging {margin-left: 2.0em}
DL.HangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.HangingInBulleted {margin-left: 4.0em}
DL.SmallHanging {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.SmallHanging {margin-left: 7.5em}
DL.SmallIndentedHanging {font-family: "Times New Roman", Times, serif; margin-left: 8.0em; margin-top: 0em; margin-bottom: 0.6em}
DD.SmallIndentedHanging {margin-left: 2.0em}
DL.SmallHangingInBulleted {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.SmallHangingInBulleted {margin-left: 5.0em}
DL.Enumerated {font-family: "Times New Roman", Times, serif; margin-right: 0.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.Enumerated {margin-left: 2.0em}
DL.SmallEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 4.0em; margin-right: 4.0em; margin-top: 0em; margin-bottom: 0.5em}
DD.SmallEnumerated {margin-left: 2.5em}
DL.NestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 2.0em; margin-right: 2.0em; margin-top: 0em; margin-bottom: 0.5em}
DL.SmallNestedEnumerated {font-family: "Times New Roman", Times, serif; margin-left: 6.0em; margin-right: 6.0em; margin-top: 0em; margin-bottom: 0.5em}
</STYLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFF0" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
<P><A HREF="AA-TOC.html">Contents</A> <A HREF="AA-0-29.html">Index</A> <A HREF="AA-3-9-3.html">Previous</A> <A HREF="AA-3-10-1.html">Next</A></P>
<HR>
<H1> 3.10 Access Types</H1>
<DIV Class="Paranum"><FONT SIZE=-2>1</FONT></DIV>
<DIV Class="Normal"> <A NAME="I2130"></A><A NAME="I2131"></A><A NAME="I2132"></A>A
value of an access type (an <I>access value</I>) provides indirect access
to the object or subprogram it <I>designates</I>. Depending on its type,
an access value can designate either subprograms, objects created by
allocators (see <A HREF="AA-4-8.html">4.8</A>), or more generally <I>aliased</I>
objects of an appropriate type. <A NAME="I2133"></A><A NAME="I2134"></A></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>1.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>A <FONT FACE="Arial, Helvetica">name</FONT>
<I>denotes</I> an entity; an access value <I>designates</I> an entity.
The ``dereference'' of an access value X, written ``X.<B>all</B>'', is
a <FONT FACE="Arial, Helvetica">name</FONT> that denotes the entity designated
by X. </FONT></DIV>
<H4 ALIGN=CENTER>Language Design Principles</H4>
<DIV Class="Paranum"><FONT SIZE=-2>1.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Access values should always be
well defined (barring uses of certain unchecked features of Section 13).
In particular, uninitialized access variables should be prevented by
compile-time rules. </FONT></DIV>
<H4 ALIGN=CENTER>Syntax</H4>
<DIV Class="Paranum"><FONT SIZE=-2>2</FONT></DIV>
<DIV Class="SyntaxIndented"><FONT FACE="Arial, Helvetica">access_type_definition<A NAME="I2135"></A>
::= </FONT><BR>
<A NAME="I2136"></A><FONT FACE="Arial, Helvetica">access_to_object_definition</FONT><BR>
| <A NAME="I2137"></A><FONT FACE="Arial, Helvetica">access_to_subprogram_definition</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>3</FONT></DIV>
<DIV Class="SyntaxIndented"><FONT FACE="Arial, Helvetica">access_to_object_definition<A NAME="I2138"></A>
::= </FONT><BR>
<B>access</B> [<A NAME="I2139"></A><FONT FACE="Arial, Helvetica">general_access_modifier</FONT>] <A NAME="I2140"></A><FONT FACE="Arial, Helvetica">subtype_indication</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>4</FONT></DIV>
<DIV Class="SyntaxIndented"><FONT FACE="Arial, Helvetica">general_access_modifier<A NAME="I2141"></A>
::= </FONT><B>all</B> | <B>constant</B></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>5</FONT></DIV>
<DIV Class="SyntaxIndented"><FONT FACE="Arial, Helvetica">access_to_subprogram_definition<A NAME="I2142"></A>
::= </FONT><BR>
<B>access</B> [<B>protected</B>] <B>procedure</B> <A NAME="I2143"></A><FONT FACE="Arial, Helvetica">parameter_profile</FONT><BR>
| <B>access</B> [<B>protected</B>] <B>function</B> <A NAME="I2144"></A><FONT FACE="Arial, Helvetica">parameter_and_result_profile</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>6</FONT></DIV>
<DIV Class="SyntaxIndented"><FONT FACE="Arial, Helvetica">access_definition<A NAME="I2145"></A>
::= </FONT><B>access</B> <A NAME="I2146"></A><FONT FACE="Arial, Helvetica">subtype_mark</FONT></DIV>
<H4 ALIGN=CENTER>Static Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>7/1</FONT></DIV>
<DIV Class="Normal"> {<I><A HREF="defect1.html#8652/0012">8652/0012</A></I>}
<A NAME="I2147"></A><A NAME="I2148"></A><A NAME="I2149"></A><A NAME="I2150"></A>There
are two kinds of access types, <I>access-to-object</I> types, whose values
designate objects, and <I>access-to-subprogram</I> types, whose values
designate subprograms. <A NAME="I2151"></A>Associated with an access-to-object
type is a <I>storage pool</I>; several access types may share the same
storage pool. <U>All descendants of an access type share the same storage
pool.</U> <A NAME="I2152"></A>A storage pool is an area of storage used
to hold dynamically allocated objects (called <I>pool elements</I>) created
by allocators[; storage pools are described further in <A HREF="AA-13-11.html">13.11</A>,
``<A HREF="AA-13-11.html">Storage Management</A>''].</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8</FONT></DIV>
<DIV Class="Normal"> <A NAME="I2153"></A><A NAME="I2154"></A>Access-to-object
types are further subdivided into <I>pool-specific</I> access types,
whose values can designate only the elements of their associated storage
pool, and <I>general</I> access types, whose values can designate the
elements of any storage pool, as well as aliased objects created by declarations
rather than allocators, and aliased subcomponents of other objects. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>8.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>The
value of an access type will typically be a machine address. However,
a value of a pool-specific access type can be represented as an offset
(or index) relative to its storage pool, since it can point only to the
elements of that pool. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9</FONT></DIV>
<DIV Class="Normal"> <A NAME="I2155"></A>A view of an object is defined
to be <I>aliased</I> if it is defined by an <FONT FACE="Arial, Helvetica">object_declaration</FONT>
or <FONT FACE="Arial, Helvetica">component_definition</FONT> with the
reserved word <B>aliased</B>, or by a renaming of an aliased view. In
addition, the dereference of an access-to-object value denotes an aliased
view, as does a view conversion (see <A HREF="AA-4-6.html">4.6</A>) of
an aliased view. Finally, the current instance of a limited type, and
a formal parameter or generic formal object of a tagged type are defined
to be aliased. [Aliased views are the ones that can be designated by
an access value.] <A NAME="I2156"></A><A NAME="I2157"></A><A NAME="I2158"></A>If
the view defined by an <FONT FACE="Arial, Helvetica">object_declaration</FONT>
is aliased, and the type of the object has discriminants, then the object
is constrained; if its nominal subtype is unconstrained, then the object
is constrained by its initial value. [Similarly, if the object created
by an <FONT FACE="Arial, Helvetica">allocator</FONT> has discriminants,
the object is constrained, either by the designated subtype, or by its
initial value.] </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Glossary entry: </B>An aliased
view of an object is one that can be designated by an access value. Objects
allocated by allocators are aliased. Objects can also be explicitly declared
as aliased with the reserved word <B>aliased</B>. The Access attribute
can be used to create an access value designating an aliased object.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The current
instance of a nonlimited type is not aliased.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The object created by an allocator
is aliased, but not its subcomponents, except of course for those that
themselves have <B>aliased</B> in their <FONT FACE="Arial, Helvetica">component_definition</FONT>.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The renaming of an aliased object
is aliased.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Slices are never aliased. See
<A HREF="AA-4-1-2.html">4.1.2</A> for more discussion. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>The current instance
of a limited type is defined to be aliased so that an access discriminant
of a component can be initialized with T'Access inside the definition
of T.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.g</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>A formal parameter of a tagged
type is defined to be aliased so that a (tagged) parameter X may be passed
to an access parameter P by using P => X'Access. Access parameters
are most important for tagged types because of dispatching-on-access-parameters
(see <A HREF="AA-3-9-2.html">3.9.2</A>). By restricting this to formal
parameters, we minimize problems associated with allowing components
that are not declared aliased to be pointed-to from within the same record.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.h</FONT></DIV>
<DIV Class="Annotations" Style="margin-bottom: 0.4em"><FONT SIZE=-1>A
view conversion of an aliased view is aliased so that the type of an
access parameter can be changed without first converting to a named access
type. For example: </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.i</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B> T1 <B>is tagged</B> ...;<BR>
<B>procedure</B> P(X : <B>access</B> T1);</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.j</FONT></DIV>
<DIV Class="SmallExamples"><TT><B>type</B> T2 <B>is new</B> T1 <B>with</B> ...;<BR>
<B>procedure</B> P(X : <B>access</B> T2) <B>is</B><BR>
<B>begin</B><BR>
P(T1(X.<B>all</B>)'Access); <I>-- hand off to T1's P</I><BR>
. . . <I>-- now do extra T2-specific processing</I><BR>
<B>end</B> P;</TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.k</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>The rule about objects with discriminants
is necessary because values of a constrained access subtype can designate
an object whose nominal subtype is unconstrained; without this rule,
a check on every use of such values would be required to ensure that
the discriminants of the object had not changed. With this rule (among
others), we ensure that if there might exist aliased views of a discriminated
object, then the object is necessarily constrained. Note that this rule
is necessary only for untagged types, since a discriminant of a tagged
type can't have a default, so all tagged discriminated objects are always
constrained anyway.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.l</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>We considered making more kinds
of objects aliased by default. In particular, any object of a by-reference
type will pretty much have to be allocated at an addressable location,
so it can be passed by reference without using bit-field pointers. Therefore,
one might wish to allow the Access and and Unchecked_Access attributes
for such objects. However, private parts are transparent to the definition
of ``by-reference type'', so if we made all objects of a by-reference
type aliased, we would be violating the privacy of private parts. Instead,
we would have to define a concept of ``visibly by-reference'' and base
the rule on that. This seemed to complicate the rules more than it was
worth, especially since there is no way to declare an untagged limited
private type to be by-reference, since the full type might by nonlimited.
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>9.m</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>Note that we
do not use the term ``aliased'' to refer to formal parameters that are
referenced through multiple access paths (see <A HREF="AA-6-2.html">6.2</A>).
</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10</FONT></DIV>
<DIV Class="Normal"> An <FONT FACE="Arial, Helvetica">access_to_object_definition</FONT>
defines an access-to-object type and its first subtype; <A NAME="I2159"></A><A NAME="I2160"></A>the
<FONT FACE="Arial, Helvetica">subtype_indication</FONT> defines the <I>designated
subtype</I> of the access type. If a <FONT FACE="Arial, Helvetica">general_access_modifier</FONT>
appears, then the access type is a general access type. <A NAME="I2161"></A>If
the modifier is the reserved word <B>constant</B>, then the type is an
<I>access-to-constant type</I>[; a designated object cannot be updated
through a value of such a type]. <A NAME="I2162"></A>If the modifier
is the reserved word <B>all</B>, then the type is an <I>access-to-variable
type</I>[; a designated object can be both read and updated through a
value of such a type]. If no <FONT FACE="Arial, Helvetica">general_access_modifier</FONT>
appears in the <FONT FACE="Arial, Helvetica">access_to_object_definition</FONT>,
the access type is a pool-specific access-to-variable type. </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>To be honest: </B>The type
of the designated subtype is called the <I>designated type</I>. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>The modifier <B>all</B>
was picked to suggest that values of a general access type could point
into ``all'' storage pools, as well as to objects declared aliased, and
that ``all'' access (both read and update) to the designated object was
provided. We couldn't think of any use for pool-specific access-to-constant
types, so any access type defined with the modifier <B>constant</B> is
considered a general access type, and can point into any storage pool
or at other (appropriate) aliased objects. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>The
predefined generic Unchecked_Deallocation can be instantiated for any
named access-to-variable type. There is no (language-defined) support
for deallocating objects designated by a value of an access-to-constant
type. Because of this, an allocator for an access-to-constant type can
allocate out of a storage pool with no support for deallocation. Frequently,
the allocation can be done at link-time, if the size and initial value
are known then. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>10.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Discussion: </B>For the purpose
of generic formal type matching, the relevant subclasses of access types
are access-to-subprogram types, access-to-constant types, and (named)
access-to-variable types, with its subclass (named) general access-to-variable
types. Pool-specific access-to-variable types are not a separately matchable
subclass of types, since they don't have any ``extra'' operations relative
to all (named) access-to-variable types. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11</FONT></DIV>
<DIV Class="Normal"> <A NAME="I2163"></A>An <FONT FACE="Arial, Helvetica">access_to_subprogram_definition</FONT>
defines an access-to-subprogram type and its first subtype; <A NAME="I2164"></A>the
<FONT FACE="Arial, Helvetica">parameter_profile</FONT> or <FONT FACE="Arial, Helvetica">parameter_and_result_profile</FONT>
defines the <I>designated profile</I> of the access type. <A NAME="I2165"></A>There
is a <I>calling convention</I> associated with the designated profile[;
only subprograms with this calling convention can be designated by values
of the access type.] By default, the calling convention is ``<I>protected</I>''
if the reserved word <B>protected</B> appears, and ``Ada'' otherwise.
[See <A HREF="AA-B.html">Annex B</A> for how to override this default.]
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>The calling
convention <I>protected</I> is in italics to emphasize that it cannot
be specified explicitly by the user. This is a consequence of it being
a reserved word. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Implementation Note: </B>For
an access-to-subprogram type, the representation of an access value might
include implementation-defined information needed to support up-level
references -- for example, a static link. The accessibility rules (see
<A HREF="AA-3-10-2.html">3.10.2</A>) ensure that in a "global-display-based"
implementation model (as opposed to a static-link-based model), an access-to-(unprotected)-subprogram
value need consist only of the address of the subprogram. The global
display is guaranteed to be properly set up any time the designated subprogram
is called. Even in a static-link-based model, the only time a static
link is definitely required is for an access-to-subprogram type declared
in a scope nested at least two levels deep within subprogram or task
bodies, since values of such a type might designate subprograms nested
a smaller number of levels. For the normal case of an access-to-subprogram
type declared at the outermost (library) level, a code address by itself
should be sufficient to represent the access value in many implementations.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.c</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>For access-to-protected-subprogram,
the access values will necessarily include both an address (or other
identification) of the code of the subprogram, as well as the address
of the associated protected object. This could be thought of as a static
link, but it will be needed even for global-display-based implementation
models. It corresponds to the value of the ``implicit parameter'' that
is passed into every call of a protected operation, to identify the current
instance of the protected type on which they are to operate.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.d</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Any Elaboration_Check is performed
when a call is made through an access value, rather than when the access
value is first "created" via a 'Access. For implementation
models that normally put that check at the call-site, an access value
will have to point to a separate entry point that does the check. Alternatively,
the access value could point to a "subprogram descriptor" that
consisted of two words (or perhaps more), the first being the address
of the code, the second being the elaboration bit. Or perhaps more efficiently,
just the address of the code, but using the trick that the descriptor
is initialized to point to a Raise-Program-Error routine initially, and
then set to point to the "real" code when the body is elaborated.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.e</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>For implementations that share
code between generic instantiations, the extra level of indirection suggested
above to support Elaboration_Checks could also be used to provide a pointer
to the per-instance data area normally required when calling shared code.
The trick would be to put a pointer to the per-instance data area into
the subprogram descriptor, and then make sure that the address of the
subprogram descriptor is loaded into a "known" register whenever
an indirect call is performed. Once inside the shared code, the address
of the per-instance data area can be retrieved out of the subprogram
descriptor, by indexing off the "known" register.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.f</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Essentially the same implementation
issues arise for calls on dispatching operations of tagged types, except
that the static link is always known "statically."</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>11.g</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>Note that access parameters of
an anonymous access-to-subprogram type are not permitted. If there were
such parameters, full ``downward'' closures would be required, meaning
that in an implementation that uses a per-task (global) display, the
display would have to be passed as a hidden parameter, and reconstructed
at the point of call. This was felt to be an undue implementation burden,
given that an equivalent (actually, more general) capability is available
via formal subprogram parameters to a generic. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>12</FONT></DIV>
<DIV Class="Normal"> <A NAME="I2166"></A><A NAME="I2167"></A><A NAME="I2168"></A>An
<FONT FACE="Arial, Helvetica">access_definition</FONT> defines an anonymous
general access-to-variable type; the <FONT FACE="Arial, Helvetica">subtype_mark</FONT>
denotes its <I>designated subtype</I>. [An <FONT FACE="Arial, Helvetica">access_definition</FONT>
is used in the specification of an access discriminant (see <A HREF="AA-3-7.html">3.7</A>)
or an access parameter (see <A HREF="AA-6-1.html">6.1</A>).]</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13</FONT></DIV>
<DIV Class="Normal"> <A NAME="I2169"></A>For each (named) access type,
there is a literal <B>null</B> which has a null access value designating
no entity at all. [The null value of a named access type is the default
initial value of the type.] Other values of an access type are obtained
by evaluating an <FONT FACE="Arial, Helvetica">attribute_reference</FONT>
for the Access or Unchecked_Access attribute of an aliased view of an
object or non-intrinsic subprogram, or, in the case of a named access-to-object
type, an <FONT FACE="Arial, Helvetica">allocator</FONT>[, which returns
an access value designating a newly created object (see <A HREF="AA-3-10-2.html">3.10.2</A>)].
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Ramification: </B>A value of
an anonymous access type (that is, the value of an access parameter or
access discriminant) cannot be null.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>13.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>Access parameters
allow dispatching on the tag of the object designated by the actual parameter
(which gets converted to the anonymous access type as part of the call).
In order for dispatching to work properly, there had better be such an
object. Hence, the type conversion will raise Constraint_Error if the
value of the actual parameter is null. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>14/1</FONT></DIV>
<DIV Class="Normal"> {<I><A HREF="defect1.html#8652/0013">8652/0013</A></I>}
<A NAME="I2170"></A><A NAME="I2171"></A>[All subtypes of an access-to-subprogram
type are constrained.] The first subtype of a type defined by an <U><FONT FACE="Arial, Helvetica">access_definition</FONT></U><S><FONT FACE="Arial, Helvetica">access_type_definition</FONT></S>
or an <FONT FACE="Arial, Helvetica">access_to_object_definition</FONT>
is unconstrained if the designated subtype is an unconstrained array
or discriminated <U>subtype</U><S>type</S>; otherwise it is constrained.
</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>14.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Proof: </B>The Legality Rules
on <FONT FACE="Arial, Helvetica">range_constraint</FONT>s (see <A HREF="AA-3-5.html">3.5</A>)
do not permit the <FONT FACE="Arial, Helvetica">subtype_mark</FONT> of
the <FONT FACE="Arial, Helvetica">subtype_indication</FONT> to denote
an access-to-scalar type, only a scalar type. The Legality Rules on <FONT FACE="Arial, Helvetica">index_constraint</FONT>s
(see <A HREF="AA-3-6-1.html">3.6.1</A>) and <FONT FACE="Arial, Helvetica">discriminant_constraint</FONT>s
(see <A HREF="AA-3-7-1.html">3.7.1</A>) both permit access-to-composite
types in a <FONT FACE="Arial, Helvetica">subtype_indication</FONT> with
such <FONT FACE="Arial, Helvetica">_constraint</FONT>s. Note that an
access-to-access-to-composite is never permitted in a <FONT FACE="Arial, Helvetica">subtype_indication</FONT>
with a <FONT FACE="Arial, Helvetica">constraint</FONT>. </FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>14.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><B>Reason: </B>Only <FONT FACE="Arial, Helvetica">composite_constraint</FONT>s
are permitted for an access type, and only on access-to-composite types.
A constraint on an access-to-scalar or access-to-access type might be
violated due to assignments via other access paths that were not so constrained.
By contrast, if the designated subtype is an array or discriminated type,
the constraint could not be violated by unconstrained assignments, since
array objects are always constrained, and aliased discriminated objects
are also constrained (by fiat, see Static Semantics). </FONT></DIV>
<H4 ALIGN=CENTER>Dynamic Semantics</H4>
<DIV Class="Paranum"><FONT SIZE=-2>15</FONT></DIV>
<DIV Class="Normal"> <A NAME="I2172"></A>A <FONT FACE="Arial, Helvetica">composite_constraint</FONT>
is <I>compatible</I> with an unconstrained access subtype if it is compatible
with the designated subtype. <A NAME="I2173"></A>An access value <I>satisfies</I>
a <FONT FACE="Arial, Helvetica">composite_constraint</FONT> of an access
subtype if it equals the null value of its type or if it designates an
object whose value satisfies the constraint.</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>16</FONT></DIV>
<DIV Class="Normal"> <A NAME="I2174"></A>The elaboration of an <FONT FACE="Arial, Helvetica">access_type_definition</FONT>
creates the access type and its first subtype. For an access-to-object
type, this elaboration includes the elaboration of the <FONT FACE="Arial, Helvetica">subtype_indication</FONT>,
which creates the designated subtype.</DIV>
<DIV Class="Paranum"><FONT SIZE=-2>17</FONT></DIV>
<DIV Class="Normal"> <A NAME="I2175"></A>The elaboration of an <FONT FACE="Arial, Helvetica">access_definition</FONT>
creates an anonymous general access-to-variable type [(this happens as
part of the initialization of an access parameter or access discriminant)].
</DIV>
<DIV Class="NotesHeader"><FONT SIZE=-1>NOTES</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>18</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>77 Access values are called
``pointers'' or ``references'' in some other languages.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>19</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>78 Each access-to-object
type has an associated storage pool; several access types can share the
same pool. An object can be created in the storage pool of an access
type by an <FONT FACE="Arial, Helvetica">allocator</FONT> (see <A HREF="AA-4-8.html">4.8</A>)
for the access type. A storage pool (roughly) corresponds to what some
other languages call a ``heap.'' See <A HREF="AA-13-11.html">13.11</A>
for a discussion of pools.</FONT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>20</FONT></DIV>
<DIV Class="Notes"><FONT SIZE=-1>79 Only <FONT FACE="Arial, Helvetica">index_constraint</FONT>s
and <FONT FACE="Arial, Helvetica">discriminant_constraint</FONT>s can
be applied to access types (see <A HREF="AA-3-6-1.html">3.6.1</A> and
<A HREF="AA-3-7-1.html">3.7.1</A>). </FONT></DIV>
<H4 ALIGN=CENTER>Examples</H4>
<DIV Class="Paranum"><FONT SIZE=-2>21</FONT></DIV>
<DIV Class="Normal" Style="margin-bottom: 0.4em"> <I>Examples of
access-to-object types:</I> </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>22</FONT></DIV>
<DIV Class="Examples"><TT><B>type</B> Peripheral_Ref <B>is access</B> Peripheral; <I>-- see <A HREF="AA-3-8-1.html">3.8.1</A></I><BR>
<B>type</B> Binop_Ptr <B>is access all</B> Binary_Operation'Class;<BR>
<I>-- general access-to-class-wide, see <A HREF="AA-3-9-1.html">3.9.1</A></I></TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>23</FONT></DIV>
<DIV Class="Wide" Style="margin-bottom: 0.4em"> <I>Example of an
access subtype:</I> </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>24</FONT></DIV>
<DIV Class="Examples"><TT><B>subtype</B> Drum_Ref <B>is</B> Peripheral_Ref(Drum); <I>-- see <A HREF="AA-3-8-1.html">3.8.1</A></I></TT></DIV>
<DIV Class="Paranum"><FONT SIZE=-2>25</FONT></DIV>
<DIV Class="Wide" Style="margin-bottom: 0.4em"> <I>Example of an
access-to-subprogram type:</I> </DIV>
<DIV Class="Paranum"><FONT SIZE=-2>26</FONT></DIV>
<DIV Class="Examples"><TT><B>type</B> Message_Procedure <B>is</B> <B>access</B> <B>procedure</B> (M : <B>in</B> String := "Error!");<BR>
<B>procedure</B> Default_Message_Procedure(M : <B>in</B> String);<BR>
Give_Message : Message_Procedure := Default_Message_Procedure'Access;<BR>
...<BR>
<B>procedure</B> Other_Procedure(M : <B>in</B> String);<BR>
...<BR>
Give_Message := Other_Procedure'Access;<BR>
...<BR>
Give_Message("File not found."); --<I> call with parameter (.<B>all</B> is optional)</I><BR>
Give_Message.<B>all</B>; --<I> call with no parameters</I></TT></DIV>
<H4 ALIGN=CENTER>Extensions to Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>26.a</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1><A NAME="I2176"></A>The syntax
for <FONT FACE="Arial, Helvetica">access_type_definition</FONT> is changed
to support general access types (including access-to-constants) and access-to-subprograms.
The syntax rules for <FONT FACE="Arial, Helvetica">general_access_modifier</FONT>
and <FONT FACE="Arial, Helvetica">access_definition</FONT> are new. </FONT></DIV>
<H4 ALIGN=CENTER>Wording Changes from Ada 83</H4>
<DIV Class="Paranum"><FONT SIZE=-2>26.b</FONT></DIV>
<DIV Class="Annotations"><FONT SIZE=-1>We use the term "storage
pool" to talk about the data area from which allocation takes place.
The term "collection" is no longer used. ("Collection"
and "storage pool" are not the same thing because multiple
unrelated access types can share the same storage pool; see <A HREF="AA-13-11.html">13.11</A>
for more discussion.) </FONT></DIV>
<HR>
<P><A HREF="AA-TOC.html">Contents</A> <A HREF="AA-0-29.html">Index</A> <A HREF="AA-3-9-3.html">Previous</A> <A HREF="AA-3-10-1.html">Next</A> <A HREF="AA-TTL.html">Legal</A></P>
</BODY>
</HTML>
|
