Re: Unconstrained Arrays

[belteshazzar <gbelteshazzar@gmail.com>]

On Mar 18, 1:33 am, Adam Beneschan <a...@irvine.com> wrote:
> 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- Hide quoted text -
>
> - Show quoted text -

Unfortuantely this is a 2005 feature and we're using 95 ... but thanks
for the tip.