Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

13.11.3 Default Storage Pools

1/3
This paragraph was deleted.{AI05-0229-1}

Syntax

2/3
{AI05-0190-1} {AI05-0229-1} The form of a pragma Default_Storage_Pool is as follows: 
3/3
{AI05-0190-1} {AI05-0229-1}   pragma Default_Storage_Pool (storage_pool_indicator);
3.1/3
{AI05-0190-1} storage_pool_indicator ::= storage_pool_name | null
3.2/3
{AI05-0190-1} A pragma Default_Storage_Pool is allowed immediately within the visible part of a package_specification, immediately within a declarative_part, or as a configuration pragma. 

Name Resolution Rules

3.3/3
  {AI05-0190-1} The storage_pool_name is expected to be of type Root_Storage_Pool'Class. 

Legality Rules

4/3
{AI05-0190-1} {AI05-0229-1} The storage_pool_name shall denote a variable.
4.1/3
  {AI05-0190-1} If the pragma is used as a configuration pragma, the storage_pool_indicator shall be null, and it defines the default pool to be null within all applicable compilation units (see 10.1.5), except within the immediate scope of another pragma Default_Storage_Pool. Otherwise, [the pragma occurs immediately within a sequence of declarations, and] it defines the default pool within the immediate scope of the pragma to be either null or the pool denoted by the storage_pool_name, except within the immediate scope of a later pragma Default_Storage_Pool. [Thus, an inner pragma overrides an outer one.]
4.2/3
  {AI05-0190-1} {AI05-0262-1} A pragma Default_Storage_Pool shall not be used as a configuration pragma that applies to a compilation unit that is within the immediate scope of another pragma Default_Storage_Pool.
4.a/3
Reason: This is to prevent confusion in cases like this: 
4.b/3
package Parent is
   pragma Default_Storage_Pool(...);
   ...
end Parent;
4.c/3
pragma Default_Storage_Pool(...); -- Illegal!
package Parent.Child is
   ...
end Parent.Child;
4.d/3
where the Default_Storage_Pool on Parent.Child would not (if it were legal) override the one in Parent.

Static Semantics

5/3
{AI05-0190-1} {AI05-0229-1} The language-defined aspect Default_Storage_Pool may be specified for a generic instance; it defines the default pool for access types within an instance. The expected type for the Default_Storage_Pool aspect is Root_Storage_Pool'Class. The aspect_definition must be a name that denotes a variable. This aspect overrides any Default_Storage_Pool pragma that might apply to the generic unit; if the aspect is not specified, the default pool of the instance is that defined for the generic unit.
5.a/3
Aspect Description for Default_Storage_Pool: Default storage pool for a generic instance.
6/3
{AI05-0190-1} {AI05-0229-1} For nonderived access types declared in places where the default pool is defined by the pragma or aspect, their Storage_Pool or Storage_Size attribute is determined as follows, unless Storage_Pool or Storage_Size is specified for the type:
6.1/3
{AI05-0190-1} If the default pool is null, the Storage_Size attribute is defined by the language to be zero. [Therefore, an allocator for such a type is illegal.]
6.2/3
{AI05-0190-1} If the default pool is nonnull, the Storage_Pool attribute is that pool.
6.3/3
  {AI05-0190-1} [Otherwise, there is no default pool; the standard storage pool is used for the type as described in 13.11.]
6.a/3
Ramification: {AI05-0190-1} {AI05-0229-1} Default_Storage_Pool is the only way to specify the storage pool for an anonymous access type.
6.b/3
{AI05-0190-1} {AI05-0229-1} Note that coextensions should be allocated in the same pool (or on the stack) as the outer object (see 13.11); the Storage_Pool of the access discriminant (and hence the Default_Storage_Pool) is supposed to be ignored for coextensions. This matches the required finalization point for coextensions.
6.b.1/3
{AI05-0190-1} The default storage pool for an allocator that occurs within an instance of a generic is defined by the Default_Storage_Pool aspect of the instantiation (if specified), or by the Default_Storage_Pool pragma that applied to the generic; the Default_Storage_Pool pragma that applies to the instantiation is irrelevant.
6.b.2/3
{AI05-0190-1} It is possible to specify the Default_Storage_Pool aspect for an instantiation such that allocations will fail. For example, the generic unit might be expecting a pool that supports certain sizes and alignments, and the one on the instance might be more restrictive. It is the programmer's responsibility to get this right.
6.b.3/3
{AI05-0190-1} The semantics of the Default_Storage_Pool aspect are similar to passing a pool object as a generic formal, and putting pragma Default_Storage_Pool at the top of the generic's visible part, specifying that formal. 
7/3
This paragraph was deleted.{AI05-0229-1}

Implementation Permissions

8/3
{AI05-0190-1} {AI05-0229-1} An object created by an allocator that is passed as the actual parameter to an access parameter may be allocated on the stack, and automatically reclaimed, regardless of the default pool.. 
8.a/3
Discussion: {AI05-0190-1} This matches the required finalization point for such an allocated object.
NOTES
9/3
32  {AI05-0190-1} Default_Storage_Pool may be used with restrictions No_Coextensions and No_Access_Parameter_Allocators (see H.4) to ensure that all allocators use the default pool. 

Wording Changes from Ada 83

9.a/3
This paragraph was deleted.{AI05-0229-1}

Incompatibilities With Ada 2005

9.b/3
{AI05-0229-1} Pragma Controlled has been dropped from Ada, as it has no effect in any known Ada implementations and it seems to promise capabilities not expected in Ada implementations. This is usually not an incompatibility, as the pragma merely becomes unrecognized (with a warning) and can be implemented as an implementation-defined pragma if desired. However, it is incompatible if it is (now) implemented as an implementation-defined pragma, someone used this pragma in a unit, and they also used restriction No_Implementation_Pragmas on that unit. In that case, the pragma would now violate the restriction; but use of this pragma (which does nothing) should be very rare, so this is not a significant issue. 

Extensions to Ada 2005

9.c/3
{AI05-0190-1} The pragma Default_Storage_Pool is new. 

Wording Changes from Ada 2005

9.d/3
{AI05-0229-1} The entire discussion of garbage collection (and especially that of controlled objects) is deleted. Ada 2012 provides subpools (see 13.11.4) for storage management of objects, including controlled objects, a mechanism which is much more predictable than garbage collection. Note that no version of Ada allows early finalization of controlled objects (other than via the use of Unchecked_Deallocation or Unchecked_Deallocate_Subpool), so that garbage collection of such objects would be ineffective in the standard mode anyway. 

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe