Diskussion:ASC

Auszug aus der PETSCII Tabelle besser in Steuerzeichen ?

hatte gerade nach den CHR$ code für Anführungszeichen gesucht und hät die nicht bei ASC vermutet (da ich den Befehl noch nie benutzt hab *g*)... hab daher erstmal den kram nach Steuerzeichen kopiert und wär dafür wenn er hier gelöscht wird.... --FXXS 12:23, 13. Aug 2006 (CEST)

Man kann ja überall, wo er eine Rolle spielt, einen Link dorthin einbauen. Ist doch ein Wiki hier. --GoDot 16:36, 13. Aug 2006 (CEST)

Hauptsache die ASCII-Tabelle ist drin. Ich hatte Sie unter ASC angelegt, da der Befehl fast so klingt wie ASCII. Ansonsten gilt es ja wie bei der Speicherbelegeungsplan, die ASCII-Tabelle benötigt einen eigenen Artikel. Andererseits es sind nur einige ASCII-Zeichen bestandteil der Steuerzeichen. --Jodigi 04:00, 14. Aug 2006 (CEST)

Beispiele mit Fehlerausgabe

Macht es Sinn Fehlbeispiele anzugeben? --Jodigi 18:16, 5. Apr. 2009 (CEST)

Das Beispiel, das ich genannt habe (?Illegal Quantity Error), macht imo einen Sinn. Denn dies ist ja kein Anwenderfehler, sondern eher ein Bug oder eine Nachlässigkeit der Programmierer, die den BASIC-Interpreter geschrieben haben. Eine leere Zeichenkette sollte immer den Wert 0 liefern, denn so ist ein Nullstring ja definiert.
Im BASIC V2 geht das aber eben nur fehlerfrei über das angehängte + chr$(0) --blubarju 06:50, 11. Apr. 2009 (CEST)

Ist vielleicht auch Ansichtssache. ASC soll ja nur von einem Zeichen den ASCll-Zahlencode ausgeben. Bei keinem Zeichen macht die Anwendnung von ASC weniger Sinn!? --Jodigi 16:11, 12. Apr. 2009 (CEST)

""+CHR$(0) gibt Null zurück, weil man NUL reingibt. Eine "leere Zeichenkette" muß einen Fehler liefern, und nicht Null. NUL ist auch ein Zeichen. Weiterhin: ASC() verlangt keine Zeichenkette sondern ein (1) _Zeichen_, das in Hochkommata angegeben werden muß, damit BASIC weiß, daß es sich um ein Zeichen und nicht um eine numerische Variable handelt. Daß Du eine Zeichenkette angeben kannst und trotzdem keinen Fehler angezeigt bekommst, ist ein Bug.

Auszug aus der Manual-Seite ASCII(7):

      Okt   Dez   Hex   Char    
      ---------------------------
      000   0     00    NUL ’\0’  <- C-Notation

HTH, Moiree 16:57, 12. Apr. 2009 (CEST)

Okay, vielleicht habe ich das mit dem Nullstring wirklich falsch erklärt. Bin aber dennoch weiterhin der Meinung, daß dieser spezielle Fall nicht unerwähnt bleiben sollte. Mit dieser Methode kann eine Fehlermeldung, und damit ein vorzeitiger und sicher auch unerwünschter Programmabbruch, verhindert werden.blubarju 18:37, 12. Apr. 2009 (CEST)

Kannst Du gerne in deinen Programmen machen, aber bitte nicht in einem Artikel über Basic-Funktionen. Sieht halt für BASIC-Anfänger/C-Umsteiger so aus, als wäre NUL-Terminierung Pflicht und dann fangen wieder alle an zu weinen, weil ein invertiertes Klammeraffensymbol an allen Zeichenketten hinten dran ist und die Länge der Zeichenketten stimmt ja auch nicht so. Hier werden ja schon die ganze Zeit Zeichen mit Zeichenketten verwechselt. Moiree 00:41, 13. Apr. 2009 (CEST)

@Moiree: "It's not a bug, it's a feature..." Der eigentliche Bug liegt darin, dass es im C64-Basic keine Mengenrepräsentation eines Leerstrings gibt. Da finde ich den Behelf mit dem Code-Null-String schon ganz in Ordnung, denn eine Funktion, die einen String bearbeiten soll, darf nicht bei einem String - und wenn es nun ein Leerstring ist - die Augen verdrehen! (Illegal Quantity) Error bei ?ASC("") ist absolut daneben... --GoDot 22:03, 12. Apr. 2009 (CEST)

ASC() verarbeitet ein _Zeichen_ und _keine_ Zeichenkette, _keine_ Zahl, _kein_ Feld und auch sonst nichts. Wenn Du kein Zeichen an die Funktion übergibst, bekommst Du einen Fehler zurück. Moiree 00:41, 13. Apr. 2009 (CEST)

Du hörst mir nicht zu. Ansonsten: Natürlich verarbeitet ASC(..) auch Strings, was redest du da? Es liefert halt die Ordnungszahl des ersten Zeichens im String zurück. Da kommt kein Fehler bei Zeichenketten. Wär auch Unsinn, denn ein Zeichen ist ja nur der Spezialfall eines Strings. --GoDot 14:24, 13. Apr. 2009 (CEST)