Der NEXT-Befehl oder "Wie ich nach über 35 Jahren nochmal überrascht werden kann"

Das war mir so auch nicht bewusst. Im Commordore C64 Handbuch steht dazu folgendes.

"Nach NEXT darf ein Variabablenname oder eine Liste von Variablen, durch Kommata getrennt stehen. Es muß immer die innerste Schleife zuerst abgearbeitet werden."

Da gilt der alte Sruch. "Man lernt nie aus"

Ja, es gibt natürlich Syntax-Varianten, die selten benutzt werden und daher auch vielen unbekannt sind.

z.B. :cont: im Programmmodus

oder loading$,8
oder saver$,8

oder forum=0 torum

oder leter=1

Schönen Gruß.

Zitat von Snoopy

Okay, ich stell mich jetzt in die Ecke. Mal schauen, was sich mir dann in nochmals 35 Jahren wieder Neues auftut.

Das kennst du auch? (macht hier so natürlich keinen Sinn)

Das macht hier so nicht direkt Sinn, das kann aber mit einem "NEXT B" nach einer IF-Abfrage durchaus mal sinnvoll sein, zumindest, wenn man es nicht so mit strukturierter Programmierung hat.

Zitat von Snoopy

habe ich immer brav mit

Code

1. 40 NEXT B
2. 50 NEXT A

abgeschlossen.

Ich wäre nie im Leben auf die Idee gekommen, dass man das auch platzsparender mit

Code

1. 40 NEXT B,A

erreichen kann.

Okay, ich stell mich jetzt in die Ecke. Mal schauen, was sich mir dann in nochmals 35 Jahren wieder Neues auftut.

Alles anzeigen

BASIC 2.0 ausnahmsweise auf Augenhöhe mit Locomotive BASIC vom CPC.

Mit Tricks kann das BasicV2 ja sogar Unterprogramme in Funktionen ausführen.

:sysfng(10): rem goto10
:sysfnp(10.20):rem setcursor10.20

Das wäre dann natürlich für den Anfänger 100% unverständlich.

Schönen Gruß.

Zitat von strik

Zitat von Snoopy

Okay, ich stell mich jetzt in die Ecke. Mal schauen, was sich mir dann in nochmals 35 Jahren wieder Neues auftut.

Das kennst du auch? (macht hier so natürlich keinen Sinn)

Code

1. 10 FOR A=1 TO 100
2. 20 FOR B=1 TO 100
3. 30 PRINT A,B
4. 40 NEXT A

Das macht hier so nicht direkt Sinn, das kann aber mit einem "NEXT B" nach einer IF-Abfrage durchaus mal sinnvoll sein, zumindest, wenn man es nicht so mit strukturierter Programmierung hat.

Ähnliches dazu: Das hab ich so bei einigen Programmen gesehen, dass etwa bewusst immer die gleiche Schleifenvariable verwendet wird und man sich somit bewusst um "offene" Schleifen nicht kümmern muss. Das FOR räumt einen etwaigen am Stack befindlichen passenden NEXT (und alle inneren) weg. Kann man leicht mit

10 FOR I=1 TO 10: GOTO 10

überprüfen -> es tritt kein Stackoverflow (OUT OF MEMORY) ein.

Das CBM-BASIC ist so gesehen sauber hinsichtlich der drohenden Speicheranomalien programmiert (was natürlich mehr Spielraum für undurchsichtigen Code lässt).

Ich habe es nie ausprobiert, aber es müsste eigentlich funktionieren.

Plan: Es soll der Wert 25 in die Variable X geschrieben werden. Und es soll eine Maschinensprache-Routine aufgerufen werden.

Die Startadresse der Maschinen-Routine in 785f. poken, dann:

X=USR(25) sollte beides erledigen.

Oder liege ich völlig daneben mit meiner Idee?

Zitat von JeeK

Das FOR räumt einen etwaigen am Stack befindlichen passenden NEXT (und alle inneren) weg.

Das macht ein RETURN übrigens auch:

Ein CLR im Übrigen auch.

Einen Obfuscated C Code Contest gibt es ja schon. Vielleicht solltet ihr mal eine BASIC-Variante davon ins Leben rufen.

Zitat von Snoopy

Ich wäre nie im Leben auf die Idee gekommen, dass man das auch platzsparender mit

Code

1. 40 NEXT B,A

erreichen kann.

Was passiert denn, wenn man hier die Variablen weglässt? Also nur "40 NEXT" ?

Zitat von Rockford

Was passiert denn, wenn man hier die Variablen weglässt? Also nur "40 NEXT"

Dann wird das NEXT der inneren Schleife zugeordnet. Hier also äquivalent zu "40 NEXT B".

Steht aber auch alles in der Beschreibung von BASIC (Handbuch, PRG) drinnen....

Zitat von Rockford

Was passiert denn, wenn man hier die Variablen weglässt? Also nur "40 NEXT" ?

Das NEXT bedient die jeweils passende (innere) Schleife. Also die zum letzten FOR-Aufruf.

Zitat von strik

Das macht ein RETURN übrigens auch:

Richtig, übrigens mit Priorität gegenüber einem NEXT-Stackframe. Umgekehrt geht es nämlich nicht.

10 FOR I=1 TO 10

20 GOSUB 30

30 NEXT

-> ?NEXT WITHOUT FOR ERROR IN 30

Der Stackfram von FOR I ist noch da, aber das GOSUB wirkt wie ein Barriere, wo also in der Subroutine anelegte FORs "unter sich", isoliert bleiben.

Zitat von strik

Zitat von JeeK

Das FOR räumt einen etwaigen am Stack befindlichen passenden NEXT (und alle inneren) weg.

Das macht ein RETURN übrigens auch:

Code

1. 10 GOSUB 100
2. 20 GOTO 10
4. 100 FOR I = 1 TO 100
5. 110 RETURN

Ausgehend von der Erläuterung durch JeeK liegt es ja eben nicht am RETURN, sondern daran, dass die Variable I in einer FOR-NEXT-Schleife erneut initialisiert wird. So gesehen wäre eher der GOSUB-Befehl verantwortlich. Aber weder der noch das RETURN sind dann letztlich ursächlich, sondern allein der FOR-Befehl.

Edit: Da war JeeK schneller. Und natürlich nehme ich alles zurück und behaupte das Gegenteil.

Es wurde hier noch nicht erwähnt, aber wenn ich mich nicht irre, ist ein

NEXT:NEXT

schneller als ein

NEXT Var1, Var2

weshalb letzteres niemand nutzt.

Zitat von -trb-

Ausgehend von der Erläuterung durch JeeK liegt es ja eben nicht am RETURN, sondern daran, dass die Variable I in einer FOR-NEXT-Schleife erneut initialisiert wird. So gesehen wäre eher der GOSUB-Befehl verantwortlich. Aber weder der noch das RETURN sind dann letztlich ursächlich, sondern allein der FOR-Befehl.

Das genannte Beispiel ist schlecht. Aber das RETURN räumt tatsächlich alle FOR-Frames weg. Es wird brutal das nächste GOSUB-Frame gesucht.

10 GOSUB 20: NEXT

20 FOR I=1 TO 10

30 RETURN

Zeigt ein "?NEXT WITHOUT FOR ERROR IN 10", weil RETURN den einzigen FOR-Stackframe weggeräumt hat. In diesem Fall ist es wirklich RETURN und nicht ein 2. oder weitere Aufruf von FOR.

Es kann übrigens ein NEXT mit expliziter Variable (abgesehen von der Geschwindigkeit) dennoch sinnvoll sein, wenn man ein äußeres "NEXT Variable" gezielt anspringt und damit die inneren FORs so nebenbei "wegputzt".