Re: formal array types and default values

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

On 12/30/2017 10:42 PM, Mehdi Saada wrote:
> 
> type T_Vect_Coef is array (T_Degre range <>) of ELEMENT;
> gives that message:
> main.adb:21:22: unconstrained subtype not allowed (need initialization)
> main.adb:21:22: provide initial value or explicit array bounds

I can't tell from the information you've provided (a small reproducer is usually 
a good idea), but this looks to me like the error msg GNAT gives for something like

S : String;

> type T_Polynome (Degre : T_Degre := 0) is -- type mutant
>      record
>          COEF : T_Vect_Coef (0..Degre) := (others => NULL_ELEMENT);
>      end record;
> gives that warning: creation of "T_Polynome" object may raise Storage_Error. Why?

Because the descriminant has a default, it's possible to declare

V : T_Polynome;

This initially has Degre => 0, but by full-record assignment, you can change the 
discriminant:

V := (Degre => 42, Coef => (0 .. 42 => Something) );

There are 2 ways a compiler can implement this. Janus/Ada will put the Coef 
component on the heap (with bounds 0 .. 0), so that the part of the record that 
is on the stack will be a constant size. If you change the discriminant, it will 
deallocate the existing Coef and allocate a new one with the new bounds. This 
approach is easier to use, but adds some overhead. For most application domains 
on most modern computers, the difference is not significant.

GNAT allocates space for the largest variant on the stack, and only uses the 
part needed by the current discriminant. When the discriminant changes, the part 
of the allocated space being used changes also. The stack is usually much 
smaller than the heap, and if T_Degre'Last is large, the amount of space to be 
allocated may exceed the size of the stack, resulting in Storage_Error. This 
approach avoids the overhead of heap allocation and deallocation, but is a bit 
less user friendly.

Some people claim that Ichbiah (the designer of Ada 83) intended this to be 
implemented the way Janus/Ada does. The Alsys and Meridian compilers also did 
this, and Alsys was Ichbiah's company, so perhaps they're correct. On the other 
hand, the DEC compiler used the same technique as GNAT, and when I heard Ichbian 
talk about the DEC compiler he had only praise for it. In the absence of a 
requirement or even advice on how to implement this in the ARM, either approach 
is correct.

There are application domains in which implicit heap allocation cannot be 
tolerated, but for most applications on modern computers with GB of RAM, the 
developer doesn't care where in RAM objects go, and it would be nice if 
compilers for such systems had a mode in which objects too large to fit on the 
stack would be automatically allocated on the heap.

-- 
Jeff Carter
"Of course, one couldn't think properly in Paris--
it was so uncomfortable and the houses were
central heated."
Clouds of Witness
153