Anonymous array clarification.

Anonymous array clarification.

[McDoobie]

In Ada one can declare anonymous arrays (an array without a type assigned
to it.)  However what would such an array be used for, and are the bounds
on it's use the same as for any other type of array.

I guess what I'm asking is if I declare an array such as 

	some_array : array(1..N);

Can I assign values such as '1' '2' '3' 'H' 'y' '-' 'foo' all to the same
array? And how would  those values be stored in memory? As Hex data with
thier values revealed according to the  context of the code block they're
in? How would I tell it to read the data stored in that block as Integers,
Chars, et...?

As a side note, I'll be downloading the source code to GNAT so that I can
get a better  understanding as to how this all works.

Any help would be appreciated.

Thanks

McDoobie

chris@dont.spam.me

Re: Anonymous array clarification.

[Phil Thornley]

"McDoobie" <chris@dont.spam.me> wrote in message
news:tY1g7.45466$K6.17744072@news2...
> In Ada one can declare anonymous arrays (an array without a type
assigned
> to it.)  However what would such an array be used for, and are the
bounds
> on it's use the same as for any other type of array.
>
> I guess what I'm asking is if I declare an array such as
>
> some_array : array(1..N);
>

You have to give the component type as well:

some_array : array(1..N) of Integer;  -- or whatever

so the question of how the components are stored doesn't arise.

On the question of what they are used for, I most commonly use them for
look-up tables.

   type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);

   Tomorrow : constant array (Day) of Day
                     := (Tue, Wed, Thu, Fri, Sat, Sun, Mon);

(which avoids a lot of stuff about 'Succ and worrying about
wrap-around).

You can't declare two anonymous arrays of the same type even in the same
declaration:

   A, B : array (1 .. 5) of Integer;

A and B are if different anonymous types and so can't be assigned
(i.e. A := B; is an illegal statement).

Note that an anonymous array can never be passed as the parameter of a
subprogram as you can't name the parameter type.

Cheers,

Phil

--
Phil Thornley
Programmes, Engineering
Warton

Re: Anonymous array clarification.

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "McDoobie" <chris@dont.spam.me>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: August 20, 2001 1:18 AM
Subject: Anonymous array clarification.


> In Ada one can declare anonymous arrays (an array without a type assigned
> to it.)  However what would such an array be used for, and are the bounds
> on it's use the same as for any other type of array.
> 
I'm not sure where you got the idea that "In Ada one can declare anonymous
arrays (an array without a type assigned to it.)."

Array objects can be declared without any name haven been given
to the _array type_, but the type of the _array elements_ must be declared.

For example, suppose you have declared some type named My_Type.

Then, you would (not using anonymous types) declare an array type like
this:

type My_Array_Type is array (Integer range <>) of My_Type;

Then, an object could be declared like this:

My_Array : My_Array_Type (1 .. 100);

Instead, using an anonymous array type, you could declare your
array object like this:

My_Array : array (1 .. 100) of My_Type;

In this case the type of My_Array is an anonymous array type,
but the elements are still of a specific type -- i.e., My_Type.
> I guess what I'm asking is if I declare an array such as 
> 
> some_array : array(1..N);
> 

The declaration you suggest is illegal.

> Can I assign values such as '1' '2' '3' 'H' 'y' '-' 'foo' all to the same
> array? And how would  those values be stored in memory? As Hex data with
> thier values revealed according to the  context of the code block they're
> in? How would I tell it to read the data stored in that block as Integers,
> Chars, et...?
> 
There are a number of ways to accomplish what you desire.

Since you speak of "reading the data," it souns like you might want to
be using an Ada.Streams.stream_Element array, and implementing a
memory stream package.  Then you can use the stream attribute of the
type of which you wish to read the data to read the data from the block.

I use thus technique a lot -- particularly in cases where the value of
some dataum read from the stream determines the type of subsequent
stream elements in the array.

 > As a side note, I'll be downloading the source code to GNAT so that I can
> get a better  understanding as to how this all works.
> 
I don't think the source code of anycompiler will do you as much good
as readsing a good Ada text regarding stream attributes, or even the
AdaLanguage Reference Manual.

> Any help would be appreciated.
> 
> Thanks
> 
> McDoobie
> 
> chris@dont.spam.me
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: Anonymous array clarification.

[Larry Hazel]

McDoobie wrote:
> 
> In Ada one can declare anonymous arrays (an array without a type assigned
> to it.)  However what would such an array be used for, and are the bounds
> on it's use the same as for any other type of array.
> 
> I guess what I'm asking is if I declare an array such as
> 
>         some_array : array(1..N);
> 
> Can I assign values such as '1' '2' '3' 'H' 'y' '-' 'foo' all to the same
> array? 

No, no.  Only the array type is anonymous.  The data type of elements must be
declared.

   some_array : array(1..N) of Integer;

Larry

Re: Anonymous array clarification.

[Samuel T. Harris]

McDoobie wrote:
> 
> In Ada one can declare anonymous arrays (an array without a type assigned
> to it.)  However what would such an array be used for, and are the bounds
> on it's use the same as for any other type of array.
> 
> I guess what I'm asking is if I declare an array such as
> 
>         some_array : array(1..N);

This is an illegal type definition and your expection that
this is valid is, I believe, the root of your other questions.

Correct to say ...

   some_array : array (1..n) of character;

... where even anonymous arrays must have the "of <subtype>" element.

> 
> Can I assign values such as '1' '2' '3' 'H' 'y' '-' 'foo' all to the same
> array? And how would  those values be stored in memory? As Hex data with
> thier values revealed according to the  context of the code block they're
> in? How would I tell it to read the data stored in that block as Integers,
> Chars, et...?

Of course, as you can see above, questions about how the
array components are interpreted are moot in that the
anonymous array definition has a specific component type.

As to storage and the other issues, just think of the above
code as equivalent to ...

  type _anonymous_some_array_type_ is array (1..n) of character;
  some_array : anonyous_some_array_type;

... where the type of object some_array is internally
generated, it just has no name explicitly represented
in your source code.

> 
> As a side note, I'll be downloading the source code to GNAT so that I can
> get a better  understanding as to how this all works.
> 
> Any help would be appreciated.
> 
> Thanks
> 
> McDoobie
> 
> chris@dont.spam.me

-- 
Samuel T. Harris, Senior Software Engineer II
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Tables vs functions (was Re: Anonymous array clarification.)

[Ray Blaak]

"Phil Thornley" <phil.thornley@baesystems.com> writes:
> On the question of what they are used for, I most commonly use them for
> look-up tables.
> 
>    type Day is (Mon, Tue, Wed, Thu, Fri, Sat, Sun);
> 
>    Tomorrow : constant array (Day) of Day
>                      := (Tue, Wed, Thu, Fri, Sat, Sun, Mon);
> 
> (which avoids a lot of stuff about 'Succ and worrying about
> wrap-around).

Hmm.

function Tomorrow(A_Day : in Day) return Day is
  Result : Day;
begin
  if A_Day < A_Day'Last then
    Result := Day'Succ(A_Day);
  else
    Result := Day'First;
  end if;
  return Result;
end Tomorrow;

Doesn't seem too complicated, looks the same to the user, is just as time
efficient, is more space efficient, and works for any size of
array/enumeration type.

It also is more robust, since one does not have to tediously type out the
items in a possibly erroneous way.

On the other hand, tables are useful when the calculations are expensive,
difficult or tedious to describe algorithmically, or the values change
according to subsequent data inputs.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Tables vs functions (was Re: Anonymous array clarification.)

[Marin David Condic]

Or as an alternative:

> function Tomorrow(A_Day : in Day) return Day is
> begin
>   return Day'Succ(A_Day);
  exception
    when Constraint_Error =>
        return Day'First ;
> end Tomorrow;

There is, of course, going to be some debate about using exceptions for
conditions you expect to happen. However, I'd point out that the code is a
bit more brief and that in some implementations it might be (on the average)
faster - for whatever that's worth. Its just an alternate implementation
style. :-)

Which would I personally use? I'd usually go with what you described. There
may be occasional uses of the Constraint_Error trap in things I write of
this nature - I'm partial to that technique when implementing saturated
arithmetic. Dunno if there is any consensus that it should be one way or
another in this case - but its a good one to put in a programming style
guideline. Like formatting rules, I'd go with whatever the style guide
recommends for a given project.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ray Blaak" <blaak@infomatch.com> wrote in message
news:un14uy8v0.fsf_-_@infomatch.com...
>
> Hmm.
>
> function Tomorrow(A_Day : in Day) return Day is
>   Result : Day;
> begin
>   if A_Day < A_Day'Last then
>     Result := Day'Succ(A_Day);
>   else
>     Result := Day'First;
>   end if;
>   return Result;
> end Tomorrow;
>
> Doesn't seem too complicated, looks the same to the user, is just as time
> efficient, is more space efficient, and works for any size of
> array/enumeration type.
>
> It also is more robust, since one does not have to tediously type out the
> items in a possibly erroneous way.
>
> On the other hand, tables are useful when the calculations are expensive,
> difficult or tedious to describe algorithmically, or the values change
> according to subsequent data inputs.
>
> --
> Cheers,                                        The Rhythm is around me,
>                                                The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside me,
> blaak@infomatch.com                            The Rhythm has my soul.

Re: Tables vs functions (was Re: Anonymous array clarification.)

[Samuel T. Harris]

Marin David Condic wrote:
> 
> Or as an alternative:
> 
> > function Tomorrow(A_Day : in Day) return Day is
> > begin
> >   return Day'Succ(A_Day);
>   exception
>     when Constraint_Error =>
>         return Day'First ;
> > end Tomorrow;
> 
> There is, of course, going to be some debate about using exceptions for
> conditions you expect to happen. However, I'd point out that the code is a
> bit more brief and that in some implementations it might be (on the average)
> faster - for whatever that's worth. Its just an alternate implementation
> style. :-)
> 
> Which would I personally use? I'd usually go with what you described. There
> may be occasional uses of the Constraint_Error trap in things I write of
> this nature - I'm partial to that technique when implementing saturated
> arithmetic. Dunno if there is any consensus that it should be one way or
> another in this case - but its a good one to put in a programming style
> guideline. Like formatting rules, I'd go with whatever the style guide
> recommends for a given project.

Consider this ...

I'm using my debugger to trap an unhandled constraint_error
and I have to skip over this one several times before I
can get to the real one. For this reason alone I prefer
to do my own checking whenever possible.

-- 
Samuel T. Harris, Senior Software Engineer II
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Tables vs functions (was Re: Anonymous array clarification.)

[Marin David Condic]

I think that anyone could take either side of the debate and come up with a
dozen or more good reasons why their side was the better approach. In the
end, you pick one for the application at hand and live with the pluses and
minuses. IMHO, if you do a lot of this sort of thing, you basically should
pick one style and be consistent about it. At least that way you have the
same problems everywhere. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Samuel T. Harris" <u61783@gsde.hou.us.ray.com> wrote in message
news:3B817AD1.2DA2DF70@gsde.hou.us.ray.com...
>
> Consider this ...
>
> I'm using my debugger to trap an unhandled constraint_error
> and I have to skip over this one several times before I
> can get to the real one. For this reason alone I prefer
> to do my own checking whenever possible.
>