First of all, thanks to all of you who replied. It transpires that there simply doesn't seem to be a way to do what I wanted.
P Witte wrote: > 1) Dimension the array to the max youre ever going to need right from the > start. (This is analogous to your suggestion re the buffer problem we > discussed earlier ;) Ie > # Its fast but greedy. and not really what I had in mind here. This was the way I had used it up to now (for about 5 years). However, the "max I was ever going to need" was exceeded a few weeks ago... The easy solution was to increase the size of the array - but since the data array was used by different programs, that meant changing & recompiling several programs... Hence my attempt to circumvent that. The problem mainly is that the data depends on what the user types in durng the day.... > 2) Use "rubber arrays" as described in the Turbo manual. > # Slow, but not too bad on "QLs" with fast drives. I don't have the Turbo manual right here - but I presume it means storing the data on a disk, then redimming the arry and re-reading it (?). If yes, I wouldn't be able to use that in a subroutine, either. > 3) Take the re-DIMentioning ouside the sub-routine. Actually, that increases the whole problem, since then you can just about forget about a subroutine in itself. I must store the data somewhere when redimming the array, and the best way I could come up with was a local array If I can't use this, then I don't need a subroutine .. > However, like the > method you suggest by your example, this could be expensive in terms > of memory, as the old memory occupied by the the array is, I believe, > not released back into the common heap (at least not in Qdos) but remains > part of the Basic area. Dont know if Qlib knows how to free that memory > again either. I never checked, either. > 4) Dont pass the array to the sub-routine as a parameter, but use the > array(s) globally. I was going to suggest using PARNAM$ here as a way of > determining which global array was to be re-dimensioned, but noticed there > is a bug in Smsq regarding this and PARSTR$. So use an extra parameter > instead: > > def proc check_array(array$,count%,new_string_to_add$, which_array%) > local b%,temp_array$ > if count%<dimn(array$,1) > array$(count%)=new_string_to_add$ > count%=count%+1 > else > [copy array to temp array] > b%=dimn(array$,2) > rem Or ON/GO TO > sel on which_array% > = 1: dim array1$(b% + 100, ..) > = 2: dim array2$(b% + 100, ..) > etc > > # Wasteful for the same reasons as (3). A tichy bit slower than the original > routine. I thought of that, too, but this make the routine unsuitable in other programs, since the names of the arrays are hardcoded > 5) If possible, use another structure than an array, eg linked list or a > tree, until the final size of the array has been determined. > # The smart solution, but may be inappropriate in certain situations. > Could be costly in S*Basic code. And is just not an option, too much of the code is geared towards arrays. > 6) A two-pass approach: First count the data, then read it. > # Not always possible, can be time consuming. Not an option either, since the data is truly dynamic in the course of the program (depends on what the user does over the course of the day). Dilwyn Jones wrote: > > In practice, I gave up, I had tried many approaches, many of which > have been mentioned in replies to this thread, and none worked > perfectly. > > (...) > The only way I could think of doing it was with a Turbo compiler > feature (forget its name) whereby if you DIMension an array which > already exists to different dimensions, the content opf the old array > was copied into the new array automatically as far as permitted by the > dimensions of the array. DIM of an array to the same size cleared the > array. That still means I'd have one function per array, unfortunately. Timothy Swenson wrote: > > The real solution to this problem is a linked list. But, SuperBasic >(and Basic in general) does not support a linked list. I believe by > definition DIMed arrays are not able to change after allocation. Well, you CAN redim them, of course. The only problem is that you can't do it in a subroutine if passing tha arary as a parameter. Linked lists are out, since the progs are geared too much towards arrays. Again, thanks to all of you!!! Wolfgang
