|
Post by dragonjim on Mar 1, 2012 15:47:18 GMT 1
This is more for information and comment than actual help. It is something I noticed when I wrote a small procedure to make up for the fact that GFA Basic doesn't have an Arrayfill() command for strings. The procedure (with accompanying programming) is below: OpenW 1 Global Dim arr$(10000) Local n For n = 1 To 10 Str_Arrayfill(10000, arr$()) Next n CloseW 1 Proc Str_Arrayfill(ct%, ByRef sa$()) Dim sa_new$(ct%) Swap sa$(), sa_new$() Erase sa_new$() EndProc The point of interest is the 'ERASE' statement in the procedure, which shouldn't be necessary. As a matter of interest, open Task Manager, and run the above program without the Erase line. You'll notice that the amount of memory GFA Basic uses jumps each time you run it; now reinsert the Erase line and you'll notice little, if any, change in memory usage. As I said at the top, this is purely for interest or comment. And, for anyone, like me, who has 4GB of memory and, after running a small GFA program for about a quarter of an hour, gets told that he's 'Out of Memory'!
|
|
|
Post by 649psoft2 on Mar 2, 2012 11:24:47 GMT 1
I haven't used Swap for a while but as I understand it the functioning for arrays is that the pointers to the arrays are swapped and not the contents.
The rule is that a Local Dim should be automatically erased.
Could it be that in this case you have swapped to an array that was declared as a Global array, therefore it assumes a that it should be Global and is not Erased (though it should). So each new Local becomes Global in the swap and is not cleaned up when losing the associated name on leaving the local procedure.
|
|
|
Post by 649psoft2 on Mar 2, 2012 11:30:24 GMT 1
I haven't used Swap for a while but as I understand it the functioning for arrays is that the pointers to the arrays are swapped and not the contents.
The rule is that a Local Dim should be automatically erased.
Could it be that in this case you have swapped to an array that was declared as a Global array, therefore it assumes a that it should be Global and is not Erased (though it should). So each new Local becomes Global in the swap and is not cleaned up when losing the associated name on leaving the local procedure.
|
|
|
Post by dragonjim on Mar 2, 2012 16:03:52 GMT 1
I must admit, I was of your way of thinking - that the Swap operation had confused the interpreter into thinking that the Local array was actually - or had become - a global array. However, investigating further, it appears that the problem occurs on all occasions whenever a Local string array is Dim'ed in a procedure or Sub, whether or not a Swap command is present.
On a positive note, this bug (if that is what it is) doesn't seem to affect the traditional numerical arrays or, as far as my experiments have shown, variant arrays.
As a bug goes, it is minor as long as you remember to include the Erase statement.
|
|
|
Post by henrik14 on Aug 12, 2012 18:57:19 GMT 1
Perhaps You should explicitely write LOCAL Dim sa_new$(ct%). In any case it is a bug since any variable declaration should start with Global or Local. I put Global xct% = 444444 Dim xsa_new$(xct%) at beginning of program and it is accepted, so it is assumed to be Global without being explicitly declared as Local Now You can explore further in regards to erasing table if it is declared Local explicitely. However such swapping as in example is meaningless, as You are assuming that newly created table is empty, which may not be the case. Next if only pointers are swapped, after erasing local table You may end with pointers pointing nowhere or at released RAM which could be assigned to something else or filled with another program so You at best get the garbage.
|
|
|
Post by dragonjim on Sept 11, 2012 14:04:35 GMT 1
Interesting point about the Local statement; it seems that the interpreter may not be differentiating between whether the Dim statement is in the main body of the program or in a subsidiary Procedure.
|
|