Wolfgang writes:
> I wonder whether anybody out there has come across the same
> problem I have, (and has found a solution).
A few possible solutions, depending on how your program uses the arrays
between re-dimensioning, etc:
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.
2) Use "rubber arrays" as described in the Turbo manual.
# Slow, but not too bad on "QLs" with fast drives.
3) Take the re-DIMentioning ouside the sub-routine. 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.
# Possibly wasteful.
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.
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.
6) A two-pass approach: First count the data, then read it.
# Not always possible, can be time consuming.
Per
