4.8 Allocators

Discussion: See 8.6, “The Context of Overload Resolution” for the meaning of “shall be a single ... type whose ...”

Ramification: {8652/0010} {AI95-00127-01} An allocator is allowed as a controlling parameter of a dispatching call (see 3.9.2).

Ramification: For example, ... new S'Class ... (with no initialization expression) is illegal, but ... new S'Class'(X) ... is legal, and takes its tag and constraints from the initial value X. (Note that the former case cannot have a constraint.)

This paragraph was deleted.{AI95-00287-01}

Reason: This prevents the allocated object from outliving its type. 

Reason: This prevents the allocated object from outliving its discriminants. 

Reason: An allocator for an access type that has Storage_Size specified to be zero is required to raise Storage_Error anyway. It's better to detect the error at compile-time, as the allocator might be executed infrequently. This also simplifies the rules for Pure units, where we do not want to allow any allocators for library-level access types, as they would represent state.

The last sentence covers the case of children of generics, and formal access types of formal packages of the generic unit. 

Discussion: See AI83-00331. 

Reason: {AI95-00363-01} All objects created by an allocator are aliased, and most aliased composite objects need to be constrained so that access subtypes work reasonably. Problematic access subtypes are prohibited for types with a constrained partial view. 

Discussion: {AI95-00363-01} If there is a constrained partial view of the type, this allows the objects to be unconstrained. This eliminates privacy breaking (we don't want the objects to act differently simply because they're allocated). Such a created object is effectively constrained by its initial value if the access type is an access-to-constant type, or the designated type is limited (in all views), but we don't need to state that here. It is implicit in other rules. Note, however, that a value of an access-to-constant type can designate a variable object via 'Access or conversion, and the variable object might be assigned by some other access path, and that assignment might alter the discriminants. 

Ramification: The conversion might raise Constraint_Error. 

Discussion: AI83-00150. 

Reason: {AI95-00344-01} The accessibility check on class-wide types prevents the allocated object from outliving its type. We need the run-time check in instance bodies, or when the type of the qualified_expression is class-wide (other cases are statically detected).

{AI95-00416-01} The accessibility check on access discriminants prevents the allocated object from outliving its discriminants. 

Reason: If the object has a controlled or protected part, its finalization is likely to be non-trivial. If the allocation was allowed, we could not know whether the finalization would actually be performed. That would be dangerous to otherwise safe abstractions, so we mandate a check here. On the other hand, if the finalization of the object will be trivial, we do not require (but allow) the check, as no real harm could come from late allocation. 

Discussion: This check can only fail if an allocator is evaluated in code reached from a Finalize routine for a type declared in the same master. That's highly unlikely; Finalize routines are much more likely to be deallocating objects than allocating them. 

Reason: A task created after waiting for tasks has finished could depend on freed data structures, and certainly would never be awaited. 

Discussion: This check is required in some cases; see above. 

Ramification: Note that in an allocator, the exception Constraint_Error can be raised by the evaluation of the qualified_expression, by the elaboration of the subtype_indication, or by the initialization. 

Discussion: By default, the implementation provides the storage pool. The user may exercise more control over storage management by associating a user-defined pool with an access type. 

{incompatibilities with Ada 83} The subtype_indication of an uninitialized allocator may not have an explicit constraint if the designated type is an access type. In Ada 83, this was permitted even though the constraint had no effect on the subtype of the created object. 

{extensions to Ada 83} Allocators creating objects of type T are now overloaded on access types designating T'Class and all class-wide types that cover T.

Implicit array subtype conversion (sliding) is now performed as part of an initialized allocator. 

We have used a new organization, inspired by the ACID document, that makes it clearer what is the subtype of the created object, and what subtype conversions take place.

Discussion of storage management issues, such as garbage collection and the raising of Storage_Error, has been moved to 13.11, “Storage Management”. 

{AI95-00363-01} {inconsistencies with Ada 95} If the designated type has a constrained partial view, the allocated object can be unconstrained. This might cause the object to take up a different amount of memory, and might cause the operations to work where they previously would have raised Constraint_Error. It's unlikely that the latter would actually matter in a real program (Constraint_Error usually indicates a bug that would be fixed, not left in a program.) The former might cause Storage_Error to be raised at a different time than in an Ada 95 program. 

{AI95-00366-01} {incompatibilities with Ada 95} An allocator for an access type that has Storage_Size specified to be zero is now illegal. Ada 95 allowed the allocator, but it had to raise Storage_Error if executed. The primary impact of this change should be to detect bugs. 

{8652/0010} {AI95-00127-01} {extensions to Ada 95} Corrigendum: An allocator can be a controlling parameter of a dispatching call. This was an oversight in Ada 95.

{AI95-00287-01} Initialized allocators are allowed when the designated type is limited. 

{8652/0002} {AI95-00171-01} Corrigendum: Clarified the elaboration of per-object constraints for an uninitialized allocator.

{AI95-00280-01} Program_Error is now raised if the allocator occurs after the finalization of the collection or the waiting for tasks. This is not listed as an incompatibility as the Ada 95 behavior was unspecified, and Ada 95 implementations tend to generate programs that crash in this case.

{AI95-00344-01} Added accessibility checks to class-wide allocators. These checks could not fail in Ada 95 (as all of the designated types had to be declared at the same level, so the access type would necessarily have been at the same level or more nested than the type of allocated object).

{AI95-00373-01} Revised the description of evaluation of uninitialized allocators to use “initialized by default” so that the ordering requirements are the same for all kinds of objects that are default-initialized.

{AI95-00416-01} Added accessibility checks to access discriminants of allocators. These checks could not fail in Ada 95 as the discriminants always have the accessibility of the object.