From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,29f8f005ed05b2f6 X-Google-Attributes: gid103376,public From: dewarr@my-dejanews.com Subject: Re: Thanks Tucker, It works !!! Date: 1998/09/20 Message-ID: <6u2nk6$p4d$1@nnrp1.dejanews.com> X-Deja-AN: 392956193 References: X-Http-Proxy: 1.0 x7.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sun Sep 20 11:06:46 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/2.02 (OS/2; I) Date: 1998-09-20T00:00:00+00:00 List-Id: In article , 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