Re: Thanks Tucker, It works !!!

[dewarr@my-dejanews.com]

In article <WishList-1909981556420001@a2.phoenix-9.goodnet.com>,
  WishList@2600.com (Technobabble) wrote:
> Greetings,
>
> The final code, which I compiled with GNAT, outputs the following:
>
> test_pkg
> test_pkg
> test_pkg
> test_pkg
> test_pkg
>
> Basically, I wanted to specify an unconstrained array in a spec for a user
> and then let the user constrain it.  Then a procedure, also in the spec,
> could determine the size of the array, in this case 5, since the loop
> executed 5 times. But I had to do it with an access type per design
> requirements.
>
> Below is the final code, I still don't really understand the aliased, all,
> and access keywords working together to allow this sort of C-like pointer
> operation, but Ada95 does allow it.  Anyone care to explain, I'd love to
> learn the reasons behind allowing pointer operations.
>
> Question:  would this work in Ada83 not having these keywords???
>
> Here is the final code:
>
> ****
> file test_pkg.ads
> ****
> package test_pkg is
>
>  type xyz_array is array (integer range <>) of integer;   -- this is it
>
>  type xyz_array_pointer is access all xyz_array;
>
>  type xyz_array_pointer_array is array (1..100) of xyz_array_pointer;
>
>  type Object is
>      record
>         XYZ : xyz_array_pointer_array;
>         abc : integer;
>      end record;
>
>  -- user can define this array externally, just here for demo
>  xyz5_array : aliased xyz_array := (1..5 => 0);
>
>  procedure my_range (This : in out Object);
>
> end test_pkg;
>
> ****
> file: my_main.adb
> ****
> with test_pkg; use test_pkg;
> procedure my_main is
>    my_this : Object;
> begin
>    my_range (my_this);
> end my_main;
>
> ****
> file: test_pkg.adb
> ****
>
> with Text_IO; use Text_IO;
> package body test_pkg is
>
> procedure my_range (This : in out Object) is
> begin
>         -- next line can be externally done by user, here for demo
>         This.XYZ(1) := xyz5_array'ACCESS;  -- address of xyz5_array is
assigned
>         for I in This.XYZ(1)'RANGE
>         loop
>           put_line ("test_pkg");
>         end loop;
>
> end my_range;
>
> end test_pkg;
>




Yes, well of course this code works, but you should never
write code you don't fully understand! It is of course
trivial to remove the gratuitous use of access in a program
like this, and it is almost certainly the case that in the
"real" code, there is also no good reason for using access.

No, of course this code will not work in Ada 83. One could
perhaps push it into working by using
'Address and unchecked conversion and hoping that the
compiler will be friendly enough for this to work (there
is no guarantee that it would).

THe introduction of aliased and the access attribute into
Ada 95 was always a controversial one. This kind of low
level pointer messing was excluded from Ada 83 for very
good reasons. It was introduced in Ada 95 for very narrow
uses. Historically, the argument that overcame many people's
great uneasiness with this feature was the need for creating
statically initialized data structures containing pointers.

Once there, the feature also has some other legitimate uses,
but I think it tends to cause more trouble than it is worth.
For example, people are often getting into trouble trying to
model external C routines by using access parameters instead
of pointer parameters. This is almost wrong because of the
(perfectly reasonable if you have the right view of things)
viewpoint that an access parameter should never be null.

Access parameters the use of 'Access also appear in the case
of function arguments to get around the (extraordinarily
idiotic) rule that functions cannot take in/out parameters.
Here is a case where the language design is simply flawed,
and so people have to get around it (try coding up the
random number packages IN THE RM sometime in Ada!)

The huge disadvantage of adding a feature like this to the
language is precisely the kind of bad code quoted here. This
code can perfectly well be written without using access (and
the rewrite is a trivial excercise). The appeal to legacy
code is very dubious, seeing as you couldn't do this in
properly written Ada 83 anyway, and if you are dealing with
junk Ada 83 code using unchecked conversion, then it might
as well be converted unchanged.

Still the feature is there. If you want to use it, you should
most certainly understand what you are doing. The use of
the aliased keyword in particular is important.

Everyone agrees that in general terms aliasing is bad. One
of the very unattractive features of a language like C is
that everything can be aliased in an arbitrary manner. The
use of 'Access in Ada 95 allows an increase in aliasing, but
we still try to control it. You can only create pointers to
variables if they have the aliased keyword. Clearly any
coding standard for Ada 95 should have the same kind of
allergy for the use of the aliased keyword that it has for
other features that are to be used only when absolutely
necessary.

Code with aliased keywords all over the place is flawed in
the same way as code with unchecked conversion all over the
place. That does not mean that neither feature should never
be used, but it means that gratuitous use, as in the above
program, is to be avoided where possible.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum