Re: Large arrays passed to arithmetic operators overflows GNAT stack

[Jerry <lanceboyle@qwest.net>]

On Dec 4, 7:17 am, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
> On 2010-12-04 01:32, Jerry wrote:
>
> > with
> >     Ada.Numerics.Long_Real_Arrays;
> > use
> >     Ada.Numerics.Long_Real_Arrays;
> > procedure array_test is
> >     type Real_Vector_Access    is access Real_Vector;
> >     N : Integer := 1_048_130;
> >     t_Ptr : Real_Vector_Access := new Real_Vector(0 .. N);
> >       t : Real_Vector renames t_Ptr.all;
>
> I don't think you need this renaming. If you do t_Ptr'Range or t_Ptr(i)
> the compiler will forward those operations directly to the object.
>  ...
> Peter

That is true but the renaming is still convenient for other reasons.
For example,
the lines

t      : Real_Vector_Access := new Real_Vector(0 .. N);
t_Diff : Real_Vector_Access := new Real_Vector(0 .. N - 1);
...
[Line 14] t_Diff := t(1 .. N);

causes the complaints

expected type "Real_Vector_Access" defined at line 14
found type "Ada.Numerics.Generic_Real_Arrays.Real_Vector" from
instance at a-nlrear.ads:18

And passing t to a vector cosine (e.g.) function that expects to see a
Real_Vector will also fail. Of course, with two like pointers t and x,
assignment  t := x assigns the pointers, not the array contents, and
with three like pointers t, x, y, t := x - y fails to find an
applicable operator function.

This clever renaming trick was mentioned by Brian Drummond in this
thread:
http://groups.google.com/group/comp.lang.ada/browse_thread/thread/ae395e5c11de7bc9/bda8d61bd3a66ee9?hl=en&q=Jerry+stack&lnk=nl&

Jerry