13.2 Packed Types
[The Pack aspect having the value True specifies that storage minimization
should be the main criterion when selecting the representation of a composite
Language Design Principles
If the default representation already uses minimal
storage for a particular type, aspect Pack might not cause any representation
change. It follows that aspect Pack should always be allowed, even when
it has no effect on representation.
As a consequence, the
chosen representation for a packed type may change during program maintenance
even if the type is unchanged (in particular, if other representation
aspects change on a part of the type). This is different than the behavior
of most other representation aspects, whose properties remain guaranteed
no matter what changes are made to other aspects.
Therefore, aspect Pack
should not be used to achieve a representation required by external criteria.
For instance, setting Component_Size to 1 should be preferred over using
aspect Pack to ensure an array of bits. If future maintenance would make
the array components aliased, independent, or atomic, the program would
become illegal if Component_Size is used (immediately identifying a problem)
while the aspect Pack version would simply change representations (probably
causing a hard-to-find bug).
For a full type declaration of a composite type, the following language-defined
representation aspect may be specified:
The type of aspect Pack is Boolean. When aspect Pack is True for a type,
the type (or the extension part) is said to be packed
. For a type
extension, the parent part is packed as for the parent type, and specifying
Pack causes packing only of the extension part.
Aspect Description for Pack: Minimize
storage when laying out records and arrays.
If directly specified, the aspect_definition
shall be a static expression. If not specified (including by inheritance),
the aspect is False.
The only high level semantic effect of specifying the Pack aspect is
potential loss of independent addressability (see 9.10
If a type is packed, then the implementation should
try to minimize storage allocated to objects of the type, possibly at
the expense of speed of accessing components, subject to reasonable complexity
in addressing calculations.
Implementation Advice: Storage allocated
to objects of a packed type should be minimized.
Specifying the Pack aspect is for gaining space efficiency, possibly
at the expense of time. If more explicit control over representation
is desired, then a record_representation_clause
a Component_Size clause, or a Size clause should be used instead of,
or in addition to, the Pack aspect.
This paragraph was
If a packed type has a component that is not of
a by-reference type and has no aliased part, then such a component need
not be aligned according to the Alignment of its subtype; in particular
it need not be allocated on a storage element boundary.
The recommended level of support for the Pack aspect
Any component of a packed type that is of a by-reference
type, that is specified as independently addressable, or that contains
an aliased part, shall be aligned according to the alignment of its subtype.
also applies to atomic components. "Atomic" implies "specified
as independently addressable", so we don't need to mention atomic
Other components do not
have to respect the alignment of the subtype when packed; in many cases,
the Recommended Level of Support will require the alignment to be ignored.
For a packed record type, the components should be packed as tightly
as possible subject to the above alignment requirements,
the Sizes of the component subtypes, and subject
that applies to the type; the implementation is
allowed to may, but need not,
components or cross aligned word boundaries to improve the packing. A
component whose Size is greater than the word size may be allocated an
integral number of words.
Ramification: The implementation can
always allocate an integral number of words for a component that will
not fit in a word. The rule also allows small component sizes to be rounded
up if such rounding does not waste space. For example, if Storage_Unit
= 8, then a component of size 8 is probably more efficient than a component
of size 7 plus a 1-bit gap (assuming the gap is needed anyway).
For a packed array type, if the Size of the component subtype is less
than or equal to the word size, Component_Size should be less than or
equal to the Size of the component subtype, rounded up to the nearest
factor of the word size, unless this would violate
the above alignment requirements
If a component subtype is aliased, its Size will
generally be a multiple of Storage_Unit, so it probably won't get packed
Implementation Advice: The recommended
level of support for the Pack aspect should be followed.
Wording Changes from Ada 95
Added clarification that the Pack aspect can ignore alignment requirements
on types that don't have by-reference or aliased parts. This was always
intended, but there was no wording to that effect.
Extensions to Ada 2005
Wording Changes from Ada 2005
Fixed so that the presence or absence of a confirming
Component_Size representation clause does not change the meaning of the
Wording Changes from Ada 2012
Corrigendum: Fixed so that the Recommended
Level of Support does not require packing of components for which such
packing would violate other representation items or aspects. This is
not incompatible, as either such Pack aspects were treated as illegal
or the Recommended Level of Support was ignored as impractical, neither
of which would change the behavior of any working programs. (Other behavior
cannot be justifed from the Reference Manual.)
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe