On 1 Apr 2013, at 09:34, Wolfgang Lenerz wrote: > > I have a problem with Qliberator. > > Consider the following program : > > 100 DEFine PROCedure increase_result_array > 110 LOCal dim1,dim2,temparray$(0,0) > 120 dim1=DIMN(result$,1) > 130 dim2=DIMN(result$,2) > 140 DIM temparray$(dim1,dim2) > 150 REMark arrcopy result$,temparray$ > 160 DIM result$(dim1+100,dim2) > 170 REMark arrcopy temparray$,result$ > 180 DIM temparray$(0) > 190 END DEFine increase_result_array > 200 : > 210 DEFine PROCedure p > 220 LOCal lp% > 230 DIM result$(1,40) > 240 FOR lp%=1 TO 90 > 250 increase_result_array > 260 END FOR lp% > 270 END DEFine p > 280 : > 290 p > 295 CLS > 300 PRINT DIMN(result$,1) > 310 kk$=INKEY$(-1) > > What is does is call the increase_result_array times, each time the result$ > array is increased by 100 elements (I've r'mmed out the parts where the old > array is copied to tthe new one and back).. > > The resulting array will have 9001 elements, 40 chars long each. > > When I run this in S, this Sbasic job occupies about 640 K (240 were already > occupied before running the prog, e.g. for the screen etc). > > OK, seems normal. > > If I compile & execute this, the resulting Qliberated job takes a whopping 32 > MB! > > It seems to me that there is a bug in the variable allocation/deallocation > routines. > > Can anybody confirm this? More importantly, does anybody know a way around > this?
1. Alter the dimensioning of temparray$ from 0,0 (and later 0!!) to 1,1 2. Use TURBO (with a large enough dataspace) George _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
