Diskussion:FIND

Hier sind mir zwei Dinge aufgefallen
(ich teste gerade, was es mit dem FIND von SBX auf sich hat, das als Schlüsselwort vorhanden, im Handbuch aber nicht erwähnt ist):

• Sucht man allerdings nach der Zeichenfolge "INT", z.B. innerhalb eines Strings, sagen wir im Wort "INTERNATIONAL", dann wird FIND diese Stelle nicht anzeigen ...

Stimmt so nicht, siehe Beispiel:

1000 A$="INTERNATIONAL":B$="ABC"

• FINDINT zeigt kein Ergebnis
• FIND"INT oder auch FIND"INTER zeigt die 1000
• FINDNAT zeigt kein Ergebnis.
• FIND"AB oder FINDBC zeigt die 1000

Beim SBX-FIND habe ich bislang als einzigen Unterschied festgestellt, dass es im obigen Beispiel

bei FINDBC kein Ergebnis zeigt. Ist also wohl eher eine Verschlechterung statt einer Verbesserung!

• Inhalte vom REM-Zeilen werden offenbar nicht untersucht

--Petrus 13:06, 3. Feb. 2011 (CET)

Doch stimmt so, denn du suchst bei deinem zweiten Beispiel nicht die Zeichenfolge INT, sondern die Folge "INT (mit führendem Quote). Über den veränderten Suchstring hinaus schaltest du in der Suchanweisung den Quote-Mode ein (mit dem Anführungszeichen), was das Tokenisieren des darauf folgenden INT im Suchstring verhindert. Daher findest du auch, was du gesucht hast. Dieses positive Ergebnis hast du aber nur bei String-Inhalten, die am Anfang des Strings liegen. Gesetzt den Fall, du suchtest INT in einem String wie "WINTER", hättest du mit FIND"INT keinen Erfolg und auch mit FINDINT nicht! Warum allerdings NAT nicht gefunden wird, ist mir ein Rätsel, es gibt kein Kommando, das NAT hieße. Auch "AT" kann es nicht sein, denn zu dessen Befehlswort gehört die öffnende Klammer dazu, es heißt also eigentlich "AT(". - Auch, dass hinter REM nichts gefunden wird, wundert mich. Hast du dabei an die Tokenisierung gedacht? --GoDot 15:23, 3. Feb. 2011 (CET) Ergänzung: Bist du sicher, dass FIND in SBX verändert wurde? --GoDot 15:27, 3. Feb. 2011 (CET)

Du hast recht. Das mit dem NAT hängt wohl mit dem Anführungszeichen zusammen, denn z.B. bei
10 A$="INTERNAT"
20 B=INTERNAT
findet FINDNAT 20, aber nicht 10.

"Auch, dass hinter REM nichts gefunden wird, wundert mich"

Zu recht, denn das ist nicht (immer) der Fall. Bei "10 REM INTEGER" findet FINDINT nichts, weil FIND INT in ein Token umwandelt, der Interpreter hinter REM aber die Zeichen so lässt. FINDGER findet 10.

FIND ist demnach zum Suchen von Schlüsselwörtern geeignet, zum Suchen von bel. Text nur sehr bedingt.

"Bist du sicher, dass FIND in SBX verändert wurde?"

Ja. FIND Token und Einsprungadressen (siehe Simons Basic Token) sind

     SB:   77  $64 $4D  FIND  $A594  $A487 (Disk,Modul)
     SBX: 108  $65 $6C  FIND         $BAE1 

Test:

     10 FINDINT
     SB-Modul:0801  09 08 0a 00  64 4d b5 00
     SBX     :0801  09 08 0a 00  65 6c b5 00

--Petrus 18:11, 3. Feb. 2011 (CET)

An den folgenden Stellen oben habe ich Unsinn erzählt:
1000 A$="INTERNATIONAL":B$="ABC"

• FIND"AB zeigt die 1000, FINDBC zeigt die 1000

Tatsächlich zeigt mit SB FINDBC kein Ergebnis.

• Beim SBX-FIND habe ich bislang als einzigen Unterschied festgestellt, dass es im obigen Beispiel bei FINDBC kein Ergebnis zeigt. Ist also wohl eher eine Verschlechterung statt einer Verbesserung!

Tatsächlich gibt es diesen Unterschied also garnicht und mein Urteil war vorschnell.

Dafür gibt es aber einen anderen, der ein Licht auf die Änderung in SBX wirft: Unter SB2 erhält man bei der obigen BASIC-Zeile mit FIND"NAT bzw. FIND"BC das Ergebnis 1000! So ist also nun die Suche nach Texten möglich. --Petrus 23:03, 3. Feb. 2011 (CET)

Fehler im Befehl FIND

Ich versuche mal, das Ergebnis der obigen Diskussion zusammenzufassen:

Bei der Suche von Textteilen in Zeichenketten versagt FIND.
Beispiel:

10 A$="INTEGER"

• FIND"GER ergibt kein Ergebnis, da FIND das Anführungszeichen mit in den Suchbegriff aufnimmt (nur der Anfang der Zeichenkette, z.B. mit FIND"INT wird gefunden).
• FINDGER ergibt auch kein Ergebnis, da so nicht in Zeichenketten gesucht wird.

Im SBX-Befehl FIND ist dieser Mangel behoben. Mit FIND"GER wird im obigen Beispiel GER in Zeile 10 gefunden, da das Anführungszeichen jetzt nicht mehr als Teil des Suchbegriffs, sondern als Steuerzeichen für 'Suche in Zeichenketten' interpretiert wird.