Re: Static expressions and using 'Size

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <4isu7e$4d0@fozzie.sun3.iaf.nl>, geert@fozzie.sun3.iaf.nl
(Geert Bosch) writes: 

|> Currently I'm writing a GC compatible allocator for GNAT
...

And I hope that in short order we'll see the garbage collector with which
it's compatible! ;-)

|> Because of portability, readability and safety I'd like not to calculate
|> all record-sizes etc. myself, but have the compiler do that for me. The
|> problem is however that expressions involving the 'Size attribute are
|> not static and for that reason cannot be used in constants.
|>
|> This is annoying because I'd rather write
|>    Page_Info_Bytes     : constant := Page_Info'Size / Byte'Size;
|> than
|>    Page_Info_Bytes     : Positive := Page_Info'Size / Byte'Size;
|> because the value of Page_Info_Bytes is known at compile-time and won't
|> change during execution of the program (I hope ;-)

The first declaration is not for a constant, but for a named number.
Nonstatic values can be used to initialize constants: 

   Page_Info_Bytes : constant Positive := Page_Info'Size / Byte'Size;
                     ^^^^^^^^^^^^^^^^^

Even though Page_Info'Size is not static from a language lawyer's point
of view (because Page_Info is a record type rather than a scalar type),
it is possible in principle for a compiler to evaluate it at compile time
if the record components all belong to static subtypes.  Some compilers
may do this.  Of course if this declaration resides in a library package,
it will be elaborated once, so this should not be a concern.

|> Things become worse when I want declare types that depend on these
|> 'constants'.

Note that the bounds in an array-type declaration need not be static,
so something like

   type Page_Info_As_Bytes is array (0 .. Page_Info_Bytes-1) of Byte;
   pragma Pack (Page_Info_As_Bytes);

would be legal.  (On the other hand,

   for Page_Info_As_Bytes'Size use Page_Info'Size;

or

   for Page_Info_As_Bytes'Size use Page_Info_Bytes * Byte'Size;

would not be.) :-(

--
Norman H. Cohen    ncohen@watson.ibm.com