Posts: 3,980
Threads: 177
Joined: Apr 2022
Reputation:
220
02-03-2024, 06:41 PM
(This post was last modified: 02-03-2024, 06:44 PM by bplus.)
I never use CLEAR, I'd rather reset all variables/arrays I need reset by saying so in code. You can maybe spot poor/redundant coding if you have to reset everything, eg you are setting something inside a loop over and over when it can be set once outside the loop which sounds a little like what OP was getting at.
b = b + ...
Posts: 1,272
Threads: 119
Joined: Apr 2022
Reputation:
100
I would try to avoid CLEAR as I, SMcNeill, and bplus have pointed out. It's just not useful for today's coding methods and is going to introduce much confusion to your code.
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Posts: 34
Threads: 6
Joined: Aug 2022
Reputation:
0
02-03-2024, 08:20 PM
(This post was last modified: 02-03-2024, 08:26 PM by bartok.)
(02-03-2024, 06:32 PM)SMcNeill Wrote: CLEAR and ERASE and any other similar command has always just seemed too unreliable, in my opinion. There's just too many various rules around their behavior. Do they affect arrays? variables? dynamic? static? ones in SUBS/FUNCTIONS? What gets erased? What gets freed completlely?
FOR I = 1 to 10
x(1) = I
NEXT
CLEAR
FOR I = 1 to 10
PRINT x(I)
NEXT
In the above, does x(I) just get reset to 0? Does it get erased and freed completely? After all, there's no call to DIM it before the first FOR, so it works just fine. IS that second FOR reusing the same variable array which has been blanked to 0, or is it a whole new array?
It's not immediately obvious what the heck is going on here, and personally I don't like that ambiguity in my code. When I'm editing and working on something at 2 AM, after a long 18-hour day, I don't want to have to dig up some manual or wrack my brain on how some esoteric and forgotten command works. I want to keep things simple:
FOR I = 1 to 10
x(1) = I
NEXT
ResetArrays
FOR I = 1 to 10
PRINT x(I)
NEXT
SUB ResetArrays
SHARED X()
FOR i = LBOUND(X) TO UBOUND(X)
X(I) = 0
NEXT
END SUB
No questions there about what's going on. It's the same array. Same position in memory, with the same offsets and such. It's just had all its values reset to the default of 0. Simple. No questions about what's going on and what is actually doing what where. It's resetting and initializing my arrays to 0.
What could possibly be simpler, or better than that?
Yes, of course, is conceptually very very simple! And for sure is a viable option... but I have to point out that it is simple until you have X(I). But I have a lot of arrays about 2, 3 and even 4 dimensions each. In order to clear them all in that way, I should write a specific long subroutine to do that, that should be modified every time in which I change or add an array, instead to a simple CLEAR. Is would be like to use SPACE$ in order to CLS the screen.
However, I found that CLEAR works. So, I posted my second question (about REDIM before CLEAR) for curiosity. My main doubt was about the first question. However, I am quite astonished that CLEAR is considered so esoteric and forgotten. How a command intended to create the same situation that exists when a program is executed (clearing all variables and arrays) could be secondary?
Posts: 34
Threads: 6
Joined: Aug 2022
Reputation:
0
(02-03-2024, 04:35 PM)TerryRitchie Wrote: (02-03-2024, 09:52 AM)bartok Wrote: (02-03-2024, 02:53 AM)TerryRitchie Wrote: I'm glad you found the tutorials useful. If you used them in 2020 then you were probably still using the old tutorial site. A lot of lessons, new code, and changes have been made since then. There were also quite a few areas in the tutorial that needed clarification for better understanding. When you get time let me know what you think of the new tutorial site and with any suggestions you may have. I used the tutorials of 2020, in 2020! But they were very very usefull: I started programming since then. I will take a look of the new ones!
Posts: 2,698
Threads: 327
Joined: Apr 2022
Reputation:
217
(02-03-2024, 08:20 PM)bartok Wrote: Yes, of course, is conceptually very very simple! And for sure is a viable option... but I have to point out that it is simple until you have X(I). But I have a lot of arrays about 2, 3 and even 4 dimensions each. In order to clear them all in that way, I should write a specific long subroutine to do that, that should be modified every time in which I change or add an array, instead to a simple CLEAR. Is would be like to use SPACE$ in order to CLS the screen.
However, I found that CLEAR works. So, I posted my second question (about REDIM before CLEAR) for curiosity. My main doubt was about the first question. However, I am quite astonished that CLEAR is considered so esoteric and forgotten. How a command intended to create the same situation that exists when a program is executed (clearing all variables and arrays) could be secondary?
If you have code which uses 3-dimensional arrays, you have some point in the code where you *must* DIM those arrays. (Unless they're all default 11 element arrays.) When you create them, just pop over to your SUB ResetArray and add them there.
SUB ResetArray
SHARED XYZ(1 to 20, 3 to 50, -17 to 97)
FOR x = LBOUND(XYZ,1) TO UBOUND(XYZ,1) <--- Highlight all this and then CTRL-C to copy it
CTRL-V <--Paste it
CTRL-V <-- Paste it
<-- Edit that X to Y and then Z
.....
You now have:
SUB ResetArray
SHARED XYZ(1 to 20, 3 to 50, -17 to 97)
FOR x = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
FOR Y = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
FOR Z = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
add the following:
XYZ(Z,Y,X) = 0
NEXT Z, Y, X
END SUB
That's it! You are now resetting your 3-dimensional array.
SUB ResetArray
SHARED XYZ(1 to 20, 3 to 50, -17 to 97)
FOR x = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
FOR Y = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
FOR Z = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
XYZ(Z,Y,X) = 0
NEXT Z, Y, X
END SUB
Quick. Simple. Unambigious.
When you add another set of arrays (or even variables which need resetting), then just pop into that SUB and add them as you code. (OR write a second ResetArrayABC command so that you can reset each array independently, as needed, without affecting the other.)
The problem with CLEAR is that it was never designed to work with modern commands. Let me ask you a few questions:
foo = _NEWIMAGE(640,480, 32)
SCREEN foo
CLEAR
Now, in the above scenario, what is supposed to happen? Should the variable foo be cleared and reset to 0? But then, how would one referecne the SCREEN called foo? Should that screen be cleared as well? Or is it memory which is now in use, but with no way to ever _FREEIMAGE it? How about variables/arrays which hold sound/font/images/ect?
How about this:
foo = 123
DIM m AS MEM
m = _MEM(foo)
CLEAR
_MEM was never a part of QB45. Does CLEAR work on it? How's it behave with CLEAR? Does that mem pointer get freed? Reset? Is it lost? Does it point to a block of memory that no longer exists? WTF is happening here?!!??
Does CLEAR work with User Defined Types? STATIC variables? COMMON SHARED variables? STATIC SUB/FUNCTION variables?
???
Honestly, I don't have a clue -- and I've been helping to develop the language here for well over a dozen years now!!
OPEN "temp.txt" FOR OUTPUT AS #foo
CLEAR
What happens with that file above? foo is the variable which references it. Is CLEAR supposed to close that file? Does it remain open, with us having no real way to know how to work with it? What's supposed to happen here? What ACTUALLY happens here???
Again, I don't have a clue.
Before I personally would feel comfortable in using CLEAR in a program, I'd have to sit down for a week and read a manual and test it with dozens of various use cases. Then I'd have to test it for another week with various cases which the manual doesn't bother to cover, as the manual was written before the new cases were ever conceived or thought of. _MEM? Not going to find it in and old QB45 reference books. _LOADIMAGE? _LOADFONT? _SNDOPEN? _EMBEDDED$? Nope. Those didn't exist in any old reference books.
The only way to be ***REALLY*** certain about how it behaves would be to sit down, test every possible case where it could affect something, and then take time to see what's going on. Read the c-output. Study the test results. Check to see exactly where and what and how things are affected....
...and then try and remember all those interactions so you can properly account for them in your own code....
OR....
Just write a quick SUB to clear what you need cleared yourself, without having to worry about corruption coming from anything else.
Posts: 1,272
Threads: 119
Joined: Apr 2022
Reputation:
100
(02-03-2024, 10:24 PM)SMcNeill Wrote: (02-03-2024, 08:20 PM)bartok Wrote: Yes, of course, is conceptually very very simple! And for sure is a viable option... but I have to point out that it is simple until you have X(I). But I have a lot of arrays about 2, 3 and even 4 dimensions each. In order to clear them all in that way, I should write a specific long subroutine to do that, that should be modified every time in which I change or add an array, instead to a simple CLEAR. Is would be like to use SPACE$ in order to CLS the screen.
However, I found that CLEAR works. So, I posted my second question (about REDIM before CLEAR) for curiosity. My main doubt was about the first question. However, I am quite astonished that CLEAR is considered so esoteric and forgotten. How a command intended to create the same situation that exists when a program is executed (clearing all variables and arrays) could be secondary?
The problem with CLEAR is that it was never designed to work with modern commands. That was my point when I went through the history of CLEAR in one of my first responses.
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Posts: 34
Threads: 6
Joined: Aug 2022
Reputation:
0
02-04-2024, 09:56 AM
(This post was last modified: 02-04-2024, 10:10 AM by bartok.)
(02-03-2024, 10:24 PM)SMcNeill Wrote: (02-03-2024, 08:20 PM)bartok Wrote: Yes, of course, is conceptually very very simple! And for sure is a viable option... but I have to point out that it is simple until you have X(I). But I have a lot of arrays about 2, 3 and even 4 dimensions each. In order to clear them all in that way, I should write a specific long subroutine to do that, that should be modified every time in which I change or add an array, instead to a simple CLEAR. Is would be like to use SPACE$ in order to CLS the screen.
However, I found that CLEAR works. So, I posted my second question (about REDIM before CLEAR) for curiosity. My main doubt was about the first question. However, I am quite astonished that CLEAR is considered so esoteric and forgotten. How a command intended to create the same situation that exists when a program is executed (clearing all variables and arrays) could be secondary?
If you have code which uses 3-dimensional arrays, you have some point in the code where you *must* DIM those arrays. (Unless they're all default 11 element arrays.) When you create them, just pop over to your SUB ResetArray and add them there.
SUB ResetArray
SHARED XYZ(1 to 20, 3 to 50, -17 to 97)
FOR x = LBOUND(XYZ,1) TO UBOUND(XYZ,1) <--- Highlight all this and then CTRL-C to copy it
CTRL-V <--Paste it
CTRL-V <-- Paste it
<-- Edit that X to Y and then Z
.....
You now have:
SUB ResetArray
SHARED XYZ(1 to 20, 3 to 50, -17 to 97)
FOR x = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
FOR Y = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
FOR Z = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
add the following:
XYZ(Z,Y,X) = 0
NEXT Z, Y, X
END SUB
That's it! You are now resetting your 3-dimensional array.
SUB ResetArray
SHARED XYZ(1 to 20, 3 to 50, -17 to 97)
FOR x = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
FOR Y = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
FOR Z = LBOUND(XYZ,1) TO UBOUND(XYZ,1)
XYZ(Z,Y,X) = 0
NEXT Z, Y, X
END SUB
Quick. Simple. Unambigious.
When you add another set of arrays (or even variables which need resetting), then just pop into that SUB and add them as you code. (OR write a second ResetArrayABC command so that you can reset each array independently, as needed, without affecting the other.)
The problem with CLEAR is that it was never designed to work with modern commands. Let me ask you a few questions:
foo = _NEWIMAGE(640,480, 32)
SCREEN foo
CLEAR
Now, in the above scenario, what is supposed to happen? Should the variable foo be cleared and reset to 0? But then, how would one referecne the SCREEN called foo? Should that screen be cleared as well? Or is it memory which is now in use, but with no way to ever _FREEIMAGE it? How about variables/arrays which hold sound/font/images/ect?
How about this:
foo = 123
DIM m AS MEM
m = _MEM(foo)
CLEAR
_MEM was never a part of QB45. Does CLEAR work on it? How's it behave with CLEAR? Does that mem pointer get freed? Reset? Is it lost? Does it point to a block of memory that no longer exists? WTF is happening here?!!??
Does CLEAR work with User Defined Types? STATIC variables? COMMON SHARED variables? STATIC SUB/FUNCTION variables?
???
Honestly, I don't have a clue -- and I've been helping to develop the language here for well over a dozen years now!!
OPEN "temp.txt" FOR OUTPUT AS #foo
CLEAR
What happens with that file above? foo is the variable which references it. Is CLEAR supposed to close that file? Does it remain open, with us having no real way to know how to work with it? What's supposed to happen here? What ACTUALLY happens here???
Again, I don't have a clue.
Before I personally would feel comfortable in using CLEAR in a program, I'd have to sit down for a week and read a manual and test it with dozens of various use cases. Then I'd have to test it for another week with various cases which the manual doesn't bother to cover, as the manual was written before the new cases were ever conceived or thought of. _MEM? Not going to find it in and old QB45 reference books. _LOADIMAGE? _LOADFONT? _SNDOPEN? _EMBEDDED$? Nope. Those didn't exist in any old reference books.
The only way to be ***REALLY*** certain about how it behaves would be to sit down, test every possible case where it could affect something, and then take time to see what's going on. Read the c-output. Study the test results. Check to see exactly where and what and how things are affected....
...and then try and remember all those interactions so you can properly account for them in your own code....
OR....
Just write a quick SUB to clear what you need cleared yourself, without having to worry about corruption coming from anything else.
Ok, I have understood.
For example, I have
DIM matrix!(2, 24, 50, 50)
I can clear it with:
FOR k% = 1 TO 2
FOR z% = 1 TO 24
FOR n% = 1 TO 50
FOR i% = 1 TO 50
matrix!(k%, z%, i%, n%) = 0
NEXT i%, n%, z%, k%
the problem is that I have hundreds of variables and tens of matrixs like the matrix above. Without counting the dynamic arrays. I have so much of this stuff that I'm myself nearly unable to count it! (I'm joking)
About the issues you said with CLEAR, I think to have avoided them. In fact, the CLEAR command is used once on the code. I can't say it is just at the beginning, because it is after the long part of declaration of variables, arrays and types, but in order to be executed more than once (the first time is when the program is launched), the flow of the program always arrives at the end of the main part of the code. As to say, it arrives just "one step" before SYSTEM. At that point, all files have been CLOSEd properly, all images are _FREEIMAGEd, and so on. It is like that beacuse I conceived the code, from the beginning, to calculate all just when the user put the inputs, and then to allow to see the results only of what the user wants to see (if he wants to). So, there is nothing left halfway before the CLEAR command is ativeted. About the other new commands about new kind of variables, I use !, %, %%, &, ~`, which are not new.
Posts: 2,698
Threads: 327
Joined: Apr 2022
Reputation:
217
02-04-2024, 12:17 PM
(This post was last modified: 02-04-2024, 12:18 PM by SMcNeill.)
If I had hundreds of variables and dozens of multi-dimensional arrays, I'd still avoid CLEAR to rerun the program. Instead, I'd:
SHELL "program_name.EXE"
SYSTEM
End the existing instance and run a new one. Never any worries then about what's freed, reset, cleared, or holding residual values.
Posts: 34
Threads: 6
Joined: Aug 2022
Reputation:
0
(02-04-2024, 12:17 PM)SMcNeill Wrote: If I had hundreds of variables and dozens of multi-dimensional arrays, I'd still avoid CLEAR to rerun the program. Instead, I'd:
SHELL "program_name.EXE"
SYSTEM
End the existing instance and run a new one. Never any worries then about what's freed, reset, cleared, or holding residual values. That's the solution! Very simple.
Posts: 383
Threads: 56
Joined: Apr 2022
Reputation:
13
You know it would sure save a lot of coding if CLEAR could be repurposed to work similar to CLOSE. Using CLOSE would close all opened files and CLOSE 3 would only close the opened file #3.
In the same fashion, rather than a multiple lines of code to reset an array or variable, it seems it may be handy to just CLEAR a, meaning to clear just the value held in the variable a but not cause 2nd variable a to exist. Same with an array..CLEAR a(14) would just clear the values held in those 15 indices and not cause a 2nd array with the same name and scope.
I will admit, the coding to reset a variable to zero is rather simple a = 0 and gets a little more complex to reset say 10 variables in a subroutine
Sub Rset
a=0
AuntFanny =0
x3 =0
FunnyAsk =0
z2z =0
End Sub
Wouldn't it be nice if CLEAR would just do ....CLEAR a,AuntFanny,x3,FunnyAsk,z2z ...without any of the overhead you guys are pointing out as a legacy with CLEAR
|