DAY 022: CLEAR

[Pete]

Do you have a clear idea of what the KEYWORD CLEAR does? If not, clear your
schedule while I clear up what CLEAR does in a clear and concise manner. So let's
clear the way and get started with some helpful do's and don't's (Hey, a double apostrophe siting!)
when using CLEAR; clear enough? If not, clear out now...

CLEAR zeros every numeric variable and nullifies every string.

CLEAR zeros the value of all arrays and also removes (de-initializes) the dimension range. All arrays will need to be re-diminsioned.

CLEAR zeros and nullifies all STATIC variables. (Variables that would otherwise retain their values in a sub-routine).

CLEAR cannot be used in a sub routine or function, only in the main.

CLEAR does not affect settings like VIEW PRINT, colors with PALETTE of fonts, window size, or cursor position, etc.

CLEAR does not destroy TYPE structure. It just makes all TYPE variables zero and all TYPE strings null.

For example...

Code: (Select All)

CONST pi = 3.14
PALETTE 0, 8 ' Black background to dark blue.
PALETTE 8, 63 ' Gray to bright white text.
DIM pete AS Perfect
TYPE Perfect
    s AS STRING
    v AS INTEGER
END TYPE

pete.s = "Pete"
COLOR 8, 0

101
PRINT pete.s;
SLEEP
CLEAR: pete.s = " is better than Steve and pi is " + LTRIM$(STR$(pi))
GOTO 101

CLEAR in QuickBasic had 2 parameters that are ignored in QB64. They were used to clear up specified amounts of stack space and memory.

CLEAR does not remove any PCOPY info.

CLEAR does not close any open files.

CLEAR acts a bit different than RUN in certain situations...

Code: (Select All)

' Let's locate and print off-screen and try to redo it. This works with CLEAR but not with RUN.
101
LOCATE 30, 1
PRINT "PRINT "Press a key loop again."
SLEEP
CLEAR
GOTO 101

Try doing that with RUN and it errors out at the LOCATE statement.

Code: (Select All)

' Let's locate and print off-screen and try to redo it. This works with CLEAR but not with RUN.
LOCATE 30, 1
PRINT "PRINT "Press a key loop again."
SLEEP
RUN

So in the first run QB64 acts like QBasic, it adjusts the screen to accommodate the off-screen print location.With CLEAR, it works but with RUN it does not duplicate that initial accommodation.

So here is the most interesting event I've found working with CLEAR over the years, the need to re-initialize a STATIC array.

Code: (Select All)

101
testsub

PRINT: PRINT "Okay, press a key..."
SLEEP
CLS
_DELAY .5
CLEAR
REDIM SHARED testarray(20) '<----------- We must remember to reinitialize our array.
GOTO 101

SUB testsub
    STATIC testarray(20)
    FOR i = 1 TO 20
        testarray(i) = i
        PRINT testarray(i): _DELAY .05
    NEXT
END SUB

For fun, try that again with the REDIM line REMmed out. It will error out at line 15.

What I think the developers should look at is RUN. RUN should not require we reinitialize anything.

This error out...

Code: (Select All)

testsub

PRINT: PRINT "Okay, press a key..."
SLEEP
CLS
_DELAY .5
RUN

SUB testsub
    STATIC testarray(20)
    FOR i = 1 TO 20
        testarray(i) = i
        PRINT testarray(i): _DELAY .05
    NEXT
END SUB

Now to get that to work would require we once again initialize our array, but this time at the top of the program.

REDIM SHARED testarray(20) ' <----------- Place this at the top of the code above and it will work.

Other differences between CLEAR and RUN are...

RUN can have a line number like RUN 101. CLEAR would need to be written as: CLEAR: GOTO 101

RUN sets the cursor to the top left. CLEAR maintains the current position.

RUN resets the RANDOMIZE sequence to the starting RND function value. (From the wiki). Clear does not reset the RND pattern.

RUN does not preserve the PALETTE or COLOR, but CLEAR does.

RUN does not preserve VIEW PRINT, but CLEAR does.

RUN and CLEAR both preserve PCOPY memory.

In general it is better practice to keep a list of all your variables and "clear" the ones you need cleared, but CLEAR
is a quick way of obtaining the same results when all your variables need to be cleared.

Another advantage of CLEAR over RUN is you can insert program control flow variables after the CLEAR statement.

Code: (Select All)

PRINT "What is my route? ": PRINT
101
SELECT CASE myroute
    CASE 0
        PRINT "Route 1"
    CASE 1
        PRINT "Route 2"
END SELECT

SLEEP
CLEAR: myroute = 1
GOTO 101

Finally RUN can be used in a SUB or FUNCTION, but CLEAR cannot. This is considered bad practice, because it creates a stack leak, which in time with excessive use will cause your program to crash.


Pete

[mnrvovrfc]

Cannot find any page that would support my arguments here, which is a shame.

"CLEAR" did lots more especially on Tandy computers. On the Color Computer it had to be used for "string space". That's why in Q(uick)BASIC the first parameter is never put down. When the Color Computer was turned on and ready to go with BASIC, it allowed only 200 characters for the storage of any number of string variables. Needed "CLEAR 1000" as the first line in the program if the programmer were sure no more than 1000 characters were needed for strings. LOL QB64 could be run on a computer with as much as 1TB RAM for a single string variable, but not the Color Computer. In fact the amount of string space ate into the space available for numeric variables and for code. To exacerbate the issue, the second parameter for that computer's statement was devised called "memend". This was necessary to "protect" a section of memory from any intrusion by the code. It was necessary for graphics but it required too much memory on a 16KB RAM computer to be sensible. So I have revealed why the first two parameters for "CLEAR" cannot be given in later BASIC's that support this keyword, and must use at least two commas always as placeholders.

Now I don't remember what the third parameter was for... until I finished writing this paragraph! The fourth one was recognized by the BASICA version that came with the Tandy1000, which was to allocate graphics memory for its exclusive graphics modes. This was necessary for "SCREEN 4" and the few other ones that Q(uick)BASIC didn't let you choose, and I couldn't choose them neither on my Tandy1000RLX because that computer came instead with VGA.

I think QuickBASIC and BASIC PDS recognized the third parameter. It was to set "stack space". C programmers for long years are very familiar with that one; stack overflow could cause some of them to cry. It had something to do with subprograms and functions written by the user. One couldn't declare too many local variables and had to keep arrays small unless they were declared with "DIM SHARED".

I learned in a children's book about BASIC programming that "DIM" had to be used instead of "CLEAR" to allocate disk space for strings on one Atari line of computers, before the ST gained fame.

Using "CLEAR" in a QB64(PE) program is simply bad practice, just don't.

[Pete]

For QuickBastc, the method I used to get the maximum amount of code lines to run was: Break the program into modules (multi-modular programming) and to add to the top...

Code: (Select All)

$DYNAMIC

CLEAR , , 2000

That addressed array size and stack space issues. I can't tell you how many times I ran up against that "Out of Stack Space" message.

Pete

[bplus]

Clearly could have been useful in my last GUI update of Accts Tracker for starting up a new file or opening an existing one.

Thumbs up to Pete for carrying on the word for the day after Steve got us addicted to it. ;-))