Re: Unconstrained Arrays

[Adam Beneschan <adam@irvine.com>]

On Mar 16, 7:58 pm, belteshazzar <gbelteshaz...@gmail.com> wrote:
> On Mar 17, 11:49 am, "Jeffrey R. Carter"
>
>
>
> <spam.jrcarter....@spam.acm.org> wrote:
> > belteshazzar wrote:
> > > I have a program that uses a lot of different sized arrays and passed
> > > into math functions. So I'm using an unconstrained array type. The
> > > problem that I have is that I'm not allowed to use "new" this means
> > > that I have to use pools (which I can't because to intantiate a pool I
> > > have to constrain the array type) or allocated the arrays on the
> > > stack. Allocating the arrays on the stack is fine, BUT it means that i
> > > have to use array initializers so that they remain unconstrained
> > > rather than becoming an anonomous contrained type that can no longer
> > > be passed to my math functions.
>
> > I'm not clear what you're talking about. You can pass a constrained subtype to a
> > subprogram that takes a parameter of an unconstrained array type.
>
> > For example, String is an unconstrained array type. If we have
>
> > function F (S : in String) return Natural;
>
> > V : String (1 .. 10);
> > C : Natural;
>
> > then it's perfectly legal to call F with V as its actual parameter:
>
> > C := F (S);
>
> > > Also, and the main point of my post, I've found that I can place the
> > > unconstrained array inside a record with a distriminant and this seems
> > > to solve all our problems. We don't have to use array initialisers and
> > > we can get pointers to aliased objects that can be easily passed to
> > > the math functions.
>
> > Here is your problem. There should be no reason to pass explicit pointers to
> > these functions. Your best solution is to rewrite or change your library.
>
> > --
> > Jeff Carter
> > "Drown in a vat of whiskey. Death, where is thy sting?"
> > Never Give a Sucker an Even Break
> > 106
>
> As we have very large array's we're using something like:
>
> type Unconstrained_Array is array ( Integer range <> ) of Integer;
> type Unconstrained_Array_Pointer is access all Unconstrained_Array;
>
> procedure F (S : in Unconstrained_Array_Pointer);
>
> V : Unconstrained_Array := (1 .. 10_000 => 0);
> V_Ptr : Unconstrained_Array_Ptr :=
> Unconstrained_Array'unchecked_Access
>
> F (V_Ptr);
>
> Note the use of the array intialiaser, if this isn't used then the
> pointer is no longer compatible.

As Jeffrey C. and Jeffrey C. have pointed out, you shouldn't use
pointers in your library routines.  Declare your library routines to
have parameters of type Unconstrained_Array and don't worry about
access types at all.  Ada makes things real simple if you let it.

If for some reason you really need to use a pointer (like maybe your
library is frozen and you can't change it without trying to sneak a
library change requisition form past a vicious CM man-wolf), I think
that in Ada 2005 you can improve performance with something like this:

V : aliased Unconstrained_Array := (1 .. 10_000 => <>);
V_Ptr : Unconstrained_Array_Ptr := V'Unchecked_Access;

This uses the "default" initializer for the element type.  Since the
default initializer for Integer is to leave it as undefined garbage,
the compiler shouldn't generate any code to set up the array.  No
guarantees, though; your compiler may do something anyway.

Also, if you were able to use 'Unchecked_Access without making V
aliased, your compiler is broken.

                                -- Adam