Next: Strict Conformance to the Ada Reference Manual, Previous: Code Generation for Array Aggregates, Up: Implementation of Specific Ada Features
If a discriminated type T
has discriminants with default values, it is
possible to declare an object of this type without providing an explicit
constraint:
type Size is range 1..100; type Rec (D : Size := 15) is record Name : String (1..D); end T; Word : Rec;
Such an object is said to be unconstrained. The discriminant of the object can be modified by a full assignment to the object, as long as it preserves the relation between the value of the discriminant, and the value of the components that depend on it:
Word := (3, "yes"); Word := (5, "maybe"); Word := (5, "no"); -- raises Constraint_Error
In order to support this behavior efficiently, an unconstrained object is
given the maximum size that any value of the type requires. In the case
above, Word
has storage for the discriminant and for
a String
of length 100.
It is important to note that unconstrained objects do not require dynamic
allocation. It would be an improper implementation to place on the heap those
components whose size depends on discriminants. (This improper implementation
was used by some Ada83 compilers, where the Name
component above
would have
been stored as a pointer to a dynamic string). Following the principle that
dynamic storage management should never be introduced implicitly,
an Ada compiler should reserve the full size for an unconstrained declared
object, and place it on the stack.
This maximum size approach has been a source of surprise to some users, who expect the default values of the discriminants to determine the size reserved for an unconstrained object: “If the default is 15, why should the object occupy a larger size?” The answer, of course, is that the discriminant may be later modified, and its full range of values must be taken into account. This is why the declaration:
type Rec (D : Positive := 15) is record Name : String (1..D); end record; Too_Large : Rec;
is flagged by the compiler with a warning:
an attempt to create Too_Large
will raise Storage_Error
,
because the required size includes Positive'Last
bytes. As the first example indicates, the proper approach is to declare an
index type of “reasonable” range so that unconstrained objects are not too
large.
One final wrinkle: if the object is declared to be aliased
, or if it is
created in the heap by means of an allocator, then it is not
unconstrained:
it is constrained by the default values of the discriminants, and those values
cannot be modified by full assignment. This is because in the presence of
aliasing all views of the object (which may be manipulated by different tasks,
say) must be consistent, so it is imperative that the object, once created,
remain invariant.