PureBoard

Das geht bei mir: das nicht: Gruß Topsoft

mh. Da hat sich Fred jetzt selbst wohin gebissen mit seiner sturren
Ansicht mit signed und unsigned Variablen. Ab 127 ist Char (Byte)
wieder -1. Somit geht die Schleife endlos weiter. Musste mit Long
arbeiten.

Hallo,

schon klar. Wollte den Bug nur dokumentieren.

Gruß Topsoft

@topsoft:
It's not a bug, it's a feature!
Also by PB-Design.

Gruß
Spider

MVXA hat geschrieben:Ab 127 ist Char (Byte)
wieder -1.

Da hab ich aber gerade einen kleinen Schock bekommen, da ich Char in meinen Libs für den RGB-Zugriff verwende !!!

Das Problem scheint jedoch (zum Glück?) nur bei Verwendung von Char als Zähler in einer For/Next Schleife so zu sein.

Wie in folgendem Beispiel zu sehen ist, funktioniert Char bei 'normaler' Verwendung wie gewohnt: Auch ist es so, dass wenn man als Zählervariable einen Char nimmt und als Endwert eine Zahl > 127, dann läuft die Schleife kein einziges mal durch.

Bsp: For Z.c = 1 To 140 läuft keinmal durch.

Es ist also wohl ein spezieller For/Next-Bug.

>> Es ist also wohl ein spezieller For/Next-Bug.
Char ist ja auch kein uByte. Kann man wohl nicht erwarten, das es sich wie eins verhält?

Laut Hilfe ist der Byte-Wertebereich von -128 bis +127 definiert.

Und der Char-1-Byte-Wertebereich von 0 bis 255. Wo ist da der Unterschied zu uByte?

Ich sehe es ganz klar als Bug.

Rainer

kann ich nur zustimmen.

wenn der wertebereich von Char als 0-255 dokumentiert ist,
muss es sich wie ein uByte verhalten, alles andere ist ein Fehler.

Hi.
Das läßt sich einfach erklären. das PB-Byte hat natürlich wie das Char auch einen "Wertebreich" der 256 "Zahlen/Werte" ermöglicht. Da es sich aber um ein vorzeichenbehaftetes Byte handelt kommt es zu dem Bereich -128 bis +127.
Das Char ist aber KEIN nummerischer Variablentyp, er dient NICHT zum rechnen. ein "Char" / "Character" ist eine "Zeichen" (wie die Zeichenkette eines Strings". Der Unterschied hierbei ist, das es sich um ein einziges Zeichen handelt, aber nicht zwangsweise nur um ein Byte. Ein Char kann auch z.B. 2 Bytes umfassen (Unicode).
Übrigens mal als Anmerkung, trotz meiner schlechten Englischkenntisse bedeutet "Character" im deutschen "Zeichen"

Einen "String" kann man ja auch nur schlecht mit einem Long vergleichen.

Und noch was, du nimmst hier als Zähler NICHT einen Char, sondern du wandelst intern den Zahlenwert in ein "Stringzeichen" um, beim nächsten durchlauf wird interen der "String" wieder in eine Zahl umgewandelt, hochgezählt und zurückgewandelt. Da kannst du als "Zähler" auch gleich einen String nehmen. Das dies anscheinend funktionert, liegt daran, das sich Chars und Bytes von der Bytebelegung her nicht unterscheiden (solange keine Unicode). Und auch hier bleibt real der Zähler auch weiterhin das "Z" aus der Schleife. beim Char machst du nichts weiter, als das Zeichen, den Buchstaben, also die Bitfolge zu ändern. Oberflächlich das selbe, real aber was ganz anderes.

Als nochmal kurz gesagt:
"Char ist ein Textzeichen, KEIN nummerischer Wert"

[edit]
Daher müßte kompeliert als ASCII-Code

Zeichen.c = 255
Zeichen +1

gleich "0" (NULL) sein,
als Unicode kompeliert müßte

Zeichen.c = 255
Zeichen +1

allerdings das Ergebnis "256" ergeben.
Hier sieht man schon mal den Unterschied.

Gruß
Toshy

@Toshy

Das ganze Thema bezieht sich - erkennbar an allen obigen Beispielen - auf 1-Byte-Char, also nicht Unicode.

Und Char-1-Byte ist ein Wert (Wert! - nichts sonst) von 0 bis 255. Der Computer speichert alle Zeichen als Wert. "A" ist der Wert 65, "µ" ist der Wert 181. Und erst unter Verwendung von Pixeltabellen (Fonts) werden diese Werte in die Pixel (z.B. des "A") umgesetzt. Ich vermute, dass auch die Pixeltabellen nummerisch aufgebaut sind.

Wie wir ein Byte im Speicher interpretieren ist Definitionssache, es kann einen Assemblerbefehl darstellen, ein Zeichen, eine Zahl (mit oder ohne Vorzeichen), einen Farbwert etc.

Chars sind (wie alles andere im Computerspeicher auch) nummerische Werte, aber anders codiert als Zahlen. Deshalb kann man Strings nicht mit Longs gleichsetzen.

Aber Chars mit der Einschränkung ein Byte sind exakt so codiert, wie eine 1-Byte-Zahl ohne Vorzeichen, von 0 bis 255, also exakt so codiert wie ein uByte.

Und man kann sehr wohl mit Char rechnen:
Und ich bin mir sicher, dass die Eins direkt addiert wird und keine Umwandlung in "Bitfolgen" geschieht. Und wenn ich mit Char rechnen kann, erwarte ich auch das korrekte Zählen in einer For-Next-Schleife, oder wie einer oben genannt hat, als RGB-Farbteil, kurz mit den Eigenschaften als uByte.

Übrigens funktioniert Char in anderen Schleifen korrekt:
und
Es wäre natürlich denkbar, dass Fred, um Operationen an ASCII-Codes zu ermöglichen, das Rechnen und Vergleichen mit Chars gestattet (deshalb würden die Rechnungen und While-Wend und Repeat-Until-Schleifen korrekt ausgeführt), aber ansonsten eine Interpretation als Char will und keine andere Interpretation gestattet (ein Char darf eben kein uByte-Zähler in einer For-Next-Schleife sein).

Diese Sichtweise wäre sehr eng gefasst, nutzerunfreundlich und im Widerspruch zu diesem Code, wo Chars als RGB-Werte korrekt funktionieren (im Unterschied zu Typ Byte .b):
Also ist es doch ein For-Next-Bug.

Rainer