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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f891f,9d58048b8113c00f X-Google-Attributes: gidf891f,public X-Google-Thread: 103376,2e71cf22768a124d X-Google-Attributes: gid103376,public X-Google-Thread: 10cc59,9d58048b8113c00f X-Google-Attributes: gid10cc59,public X-Google-Thread: 1014db,9d58048b8113c00f X-Google-Attributes: gid1014db,public From: cwarack@cs.usafa.af.mil (Chris Warack ) Subject: Re: next "big" language?? (disagree) Date: 1996/06/11 Message-ID: <4pki88$gpq@usafa2.usafa.af.mil>#1/1 X-Deja-AN: 159673654 distribution: usafa sender: cwarack@kirk.usafa.af.mil (Chris Warack ) references: <4p3nqb$k4a@btmpjg.god.bel.alcatel.be> <4p3nto$k4a@btmpjg.god.bel.alcatel.be> <4pj7e0$fat@goanna.cs.rmit.EDU.AU> organization: USAFA Dept of Computer Science newsgroups: comp.lang.ada,comp.lang.pascal,comp.lang.c,comp.lang.misc Date: 1996-06-11T00:00:00+00:00 List-Id: In article <4pj7e0$fat@goanna.cs.rmit.EDU.AU>, rav@goanna.cs.rmit.EDU.AU (++ robin) writes: |> Richard Riehle from San Diego writes: |> |> >> Robin, from Australia raplied. |> >> |> >> "---Why, someone inevitably decides that the range is going |> >> to be something different! Users are apt to change their minds. |> >> Then someone has to go in and modify the program. Or, someone |> >> overlooked a limit, and put in a limit one smaller than that |> >> actually required. Again, someone has to go in and find where |> >> that limit is, and change it." |> |> > Good point. This is one of the very reasons why Ada works so well |> > for this kind of thing, when programs are written correctly. In |> > particular, when one takes advantage of the availability of |> > attributes. Let's say that we establish a range of 1 through 10 for some |> > type T1. Then we write a program using variables of that type. |> |> > For example, we define the type T1, and an unconstrained array as follows: |> |> > type T1 is range 1..10; |> > type Vector is array(Positive range <>) of Float; |> |> > Then we declare a variable of type Vector: |> |> > Float_Set : Vector(T1'First..T1'Last); |> |> > Some algorithm, elsewhere in the code can be written as: |> |> > for I in Float_Set'Range loop ... end loop; |> ... |> |> ---One of the problems of using rigid facilities -- amply |> illustrates my point. Arrays don't often have fixed sizes. |> The size depends on the problem. One day, it might be 10, |> next day, 300, day after, 90. |> |> Are you seriusly suggesting that EACH time the program |> is run that it be edited and recompiled? And what |> happens -- as is often the case -- the size of the array |> changes DURING the run? No. If that's the case change the declaration of T1 to: subtype T1 is positive range 1 .. What_ever_the_value_is_today; * or subtype T1 is positive range 1 .. This_runs_size; or type Vector is private; if you really want to make it behave in some special manner. or ... * Recognizing that T1 really needed to be a subtype in the example above In those first two examples, it doesn't matter how the upper values are set (e.g., hardware, sensor, data file, user input ...) and this works fine. It's not too hard to change from the rigid approach to this more flexible approach either. It does preclude some possibilities for static optimizations perhaps. The last alternative is a serious change to the given example. When you don't want to use an array, however, you shouldn't use an array then. Define the dynamic data structure of your dreams in whatever way you see fit. -- Christopher A. Warack, Capt, USAF cwarack@cs.usafa.af.mil (719) 472-2401 Computer Science Department, US Air Force Academy This content in no way reflects the opinions, standards, or policy of the USAF Academy, or the US government.