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: 10cc59,9d58048b8113c00f X-Google-Attributes: gid10cc59,public X-Google-Thread: 103376,2e71cf22768a124d X-Google-Attributes: gid103376,public From: "Kevin J. Weise" Subject: Re: next "big" language?? (disagree) Date: 1996/06/11 Message-ID: <4pkk51$t31@michp1.redstone.army.mil>#1/1 X-Deja-AN: 159702352 references: <4p3nqb$k4a@btmpjg.god.bel.alcatel.be> <4p3nto$k4a@btmpjg.god.bel.alcatel.be> <4pj7e0$fat@goanna.cs.rmit.EDU.AU> <4pk9q9$a9j@ss2.cs.mci.com> content-type: text/plain; charset=us-ascii organization: Redstone Arsenal, Alabama mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.pascal x-mailer: Mozilla 1.22 (Windows; I; 16bit) Date: 1996-06-11T00:00:00+00:00 List-Id: James_Rogers wrote (with deletions): >rav@goanna.cs.rmit.EDU.AU (++ robin) wrote: > >> 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? > >Now you are approaching the real problem. Arrays are must >always have a specific size. That size may be defined at >compile time or it may be det4rmined at run time using >dynamic allocation. Either way a given instance of an array >does not change its size. If this is not enough reason to >use some other more dynamic data structure such as a list or >a tree, then the common methods used with arrays include the >concept of declaring a size which is the largest expected for >current needs. A subset of that array is typically used for >the problem at hand, wasting the remainder for future growth. > >The point is that every array must be accompanied by some method >of indicating the specific subset of elements to be processed. >In C this means one typically either passes an array pointer and >a size parameter, or a special character is expected to be >embedded in the array to mark the end of useful data ( the NULL >character, for instance). Methinks you missed one other alternative, Mr. Rogers. It is also possible to elaborate, at runtime, an array of appropriate size without having to use dynamic (i.e., heap) memory. E.g.: procedure Made_Up_Example (MAX_SIZE : Natural) is THIS_STRING : String (1..MAX_SIZE); begin -- whatever end Made_Up_Example; Obviously, the parameter value cannot be expected to be static, so you (and the compiler) can safely assume the amount of memory needed for THIS_STRING will probably vary from one invocation to another. (In fact, the memory gets allocated for it on the stack when its declaration is elaborated.) Then you only need to figure out how big an array you need *before* invoking your subprogram. This works great with blocks,too. On nice machines that let your stack space float to however much virtual memory your program needs, you can have great flexibility without having to use the heap or the old FORTRAN-style "declare it as big as your biggest possible need" method. And you don't have to edit/recompile/relink everytime the size changes! The only problem I recall having with this is when the subprogram (or block) is executed within the context of a task whose default stack size is insufficient to handle the block creation. But that is relatively easy to solve with a 'Size pragma. ------------------------------------------------------------- Kevin J. Weise kweise@c3i-ccmail.sed.redstone.army.mil COLSA Corporation voice: (205) 842-9680 Huntsville, AL