I've always kind of wondered:  Why does no one ever mention the FILES command?

Because it's kind of useless if you need an array with a list of filenames, say for a file picker.

Honestly, I don't see anything wrong with what you've got here.  (Though I imagine that GOTO would probably be in an IF condition or such instead of just stand-alone.)

It causes memory leaks, specifically in the stack. Since the NEXT doesn't get executed, the FOR's spot on the stack doesn't get removed, causing the stack to be pointing at the wrong place after exiting the loop. In extreme cases, this could cause errors further down the program, such as RETURN going to the wrong place or just running out of stack space if that loop gets repeated often.

Also, if this loop is contained inside a larger loop, this could cause the NEXT to advance the wrong loop. Consider this example

For I = 1 To 10
    For J = 1 To 10
        GoTo AfterJ
    Next
    AfterJ:
Next
Print I, J

On some BASICs, this actually prints 1,10. This is because the second NEXT actually advances J, rather than I. This is because BASIC doesn't know or care which FOR is being advanced. It just iterates the first loop in the stack and goes back to that line.

QB64 actually does this correctly (and presumably unwinds the stack on the GOTO out), but it's still unwise policy.


If you do need to exit a loop early, you should use the EXIT FOR command, which should properly unwind the stack.


Also, in some languages, the loop counter (I) also goes out of scope after the loop completes, so it's never wise to count on a loop control variable's state after a loop. In fact, some compilers (I think c# does this) will actually throw an error when attempting to reference a control variable after a loop has completed.

If you do need to preserve the counter when you reach an early exit state, you can save it off to another variable. But there's another important consideration: FOR  actually the wrong construct to use when you may need to bail early. If you're doing something like searching a list or checking a range of values, that's actually what a WHILE loop is for.

Take this example of a linear search:


FOR I = 1 TO 100
  IF Domain(I) = Match THEN EXIT FOR
NEXT

This is actually better done as a WHILE loop, since WHILE signals that we may be exiting early:

I = 1
WHILE Domain(i) <> Match AND I <= UBOUND(Domain)
  I = I + 1
WEND

Either of these examples will work, but the latter example is more correct. This is because the thing we are looking for (Match) is canonically part of the loop condition, rather than being a line inside the loop somewhere.

Hi @tomxp411,

please read the wiki page for Select Case and note well we have a EVERYCASE keyword here in qb64, which was actually used in @SMcNeill 's example.

But on the other hand I do also agree with you, that IFs without ELSE branch do it best here, what is actually what SELECT EVERYCASE does.

His last message was an IF/ELSE block, which would have failed in exactly the way I described.

EVERYCASE could be made to work, but it's also going to be more complex than what I posted, for the reasons I already gave: he really needs to settle all of his conditions before entering his CASE statement.

Looking at the example given, this is not what SELECT CASE is for.

CASE statements are always meant to be mutually exclusive, and you can only pick one. Flow must always go from SELECT to a single CASE to END SELECT. Flow is not allowed to move between cases, or you get "spaghetti code."

So looking at your example... You're doing to much in one CASE block. You're still trying to figure out what your event is, and you need to identify that first, then act on it.

So you need some IF statements first, to properly parse your event and your outside parameters (Temperature, Snow Days, and Wind Speed) and then use the answer to make the correct calculation.


Note that I purposely did NOT use ELSE on the series of IF statements, because it's possible for event 1 to fall through to 2, 3, and 4. Event 2 can fall through to 3 and 4, and 3 can fall through to 4. So an event that starts as 1 must be tested up to 3 times. Using ELSE IF would skip the later tests.

@SMcNeill this is why your example doesn't quite work: Take a rain event where it's -10 degrees and the wind is blowing at 120. In this case, the correct case is "Hurricane". However, your code will fall through without incrementing any of the counters.

Ok, let's start with: you don't need TEMP$ or the array. You definitely do not want an array of string*92126 objects. That gives you 92126*92126 characters, which is over 8GB.

You should be able to load data straight into a string*, like this:

I'd like to apply. I'd like to think I'm pretty good at writing example code, documenting software, and generally being helpful.

I've been programming BASIC since the 80s... BASIC 2, Quick BASIC, Visual BASIC, and now QB64, and I also work for a technology company you'd have heard of (I don't talk about it in public forums, but feel free to PM me to ask for details.)

No, there was no need for assembly. Coders just had to call an interrupt, and the parameter going in determined whether you'd get back the X or Y position of the pointer, or the button state.

http://www.petesqbsite.com/sections/tutorials/zines/basix/3-mouse.txt