Version 1.5 of ai05s/ai05-0152-1.txt
!standard H.4(8/1) 09-10-12 AI05-0152-1/03
!class Amendment 09-05-23
!status Amendment 201Z 09-06-25
!status WG9 Approved 09-11-05
!status ARG Approved 6-0-0 09-06-14
!status work item 09-05-23
!status received 09-05-23
!subject Restriction No_Anonymous_Allocators
Add restriction_identifier No_Anonymous_Allocators.
Allocators for anonymous access types have various special properties that
make them very different than allocators for named access types:
(1) Allocators for anonymous access parameters are supposed to allocate
the object from a pool "created at the point of the allocator"; the
object has the innermost master surrounding the allocator as the anonymous
access type is created at the point of each call, and thus the object
is finalized right after the call (13.11(25.2/2), 6.4.1(9), 7.6.1(11/2)).
(2) Allocators for anonymous access discriminants cause "coextensions",
with their own set of rules and implementation overhead.
(3) Allocators for other kinds of anonymous access types create objects
with the accessibility of the point of the access_definition. This means
that there is little control over the accessibility of the allocated
object. The storage pool used "need not support" deallocation
In addition, for all kinds of anonymous access types, the use of specified
(user-defined) storage pools is not possible. Nor is the use of
These properties make using anonymous access types as a complete replacement
for named access types impossible. For that sort of use, it is better to use
a named access type (for which control over the storage pool, object lifetime,
and deallocation is possible) to do allocation, then convert to anonymous access
types as needed. If this model is being followed, directly allocating an
object of an anonymous access type is a mistake.
Add after H.4(8/1):
No_Anonymous_Allocators Allocators of anonymous access types are not allowed.
Anomymous access types cannot be passed as generic formal types, so we don't have
to worry about generic cases here.
pragma Restrictions (No_Anonymous_Allocators);
package P is
procedure Proc (X : access Integer);
procedure Test is
P.Proc (new Integer'(10)); --
Insert after the paragraph:
- Allocators are prohibited in subprograms,
generic subprograms, tasks, and entry bodies.
the new paragraph:
- Allocators of anonymous access types are
Add an ACATS test for this new feature.
This AI was split from AI05-0138-1; there is a small amount of discussion
on this idea in the volumous e-mail in that AI.
Questions? Ask the ACAA Technical Agent