Und wenn du danach gehst das Char genau wie eine "unsigned" Bytevariable ist, dann muß du aber dazu sagen, das eine "unsigned" auch genau so aufgebaut ist wie eine "signed". Normalerweise gibt es dort im Byteaufbau keinen Unterschied. nur die Interpretation durch Funktionen ist unterschiedlich.
Dann kannst du auch genau so zahl.s nehmen, Strings sind in den meißten fällen so gesehen auch nichts weiter als "zahlen Variabelen", nur halt 4 Byte lang als Pointer. Theoretisch kann man auch rechnen, aber machne Dinge sind halt aus einem ganz bestimmten Grund für bestimmte Dinge gedacht.
Wenn man also mit einem Char wirklich "rechnen will", geht das zwar an sich, ist aber dafür einfach nicht gedacht.
Ich nutze auch in einigen Fällen so eine Krücke, da aber mit Sinn. Zum Beispiel kopiere ich Floats in Longs und umgekehrt. Allerdings mache ich das als Speicherkopie. Dadurch kann ich beim hin und her kopieren mit "in Longs versteckten Floats" die Nutzung der FPU umgehen (um die FPU so für anders freizuhalten). Das hat jetzt zwar nicht mit dem "Charproblem" direkt zu tun, aber auch hier kann man Dinge für was nutzen, wofür sie nicht gedacht sind. Wenn damit aber bestimmte Dinge nicht nutzbar sind (hier bei mir direkt mit den Longs rechnen), dann darf m an sich nicht beschweren.
Und man muß sehr wohl beachten das es auch Unicode gibt. Zwar willst du es vielleicht nicht nutzen, aber an Unicode (ist ja keine PB-Angelegenheit, sondern eine vom Betriebssystem) müßtest du doch erkennen, das Char NICHT in "verkapptes" uByte ist. Alle nummerischen Variablen behalten immer ihre Länge, egal in welchem Betriebssystem bzw. wie kompeliert, Zeichenvariablen nicht.
Kurz gesagt, man kann alles, so auch Char zum Rechnen nehmen, aber das ist halt nicht korrekt.
Das Thema bezieht sich also nicht einfach nur auf das 1-Byte-Char, sondern auf den Verständnisfehler was ein Char ist und wozu er dient.
Char ist genau so unterschiedlich zu nummerischen Variablen wie Longs,Bytes, wie auch diese unterschiedlich zu Floats und Doubles sind.
uByte, sByte, Char (Ascii), Memory (1-Byte) sind nur in einer Art das selbe, sie belegen 8 Bit. Mehr nicht.
Memory (4Byte), Long, Float, String, *Pointer sind genau so das selbe (wie in der von dir gemeinten Art) denn sie nutzen alle 32 Bit.
Aber das war auch schon das einzige wirklich gemeinsame.
Char ist nicht ein uByte. Es hat hier nur "zufällig" die selbe Bitanzahl.
Alles wird in "Nullen und Einsen" verarbeiten (Bits), das ist das einzige was wirklich stimmt. Aber nummerische Werte werden nicht prinzipiell anders kodiert als Chars. uByte, sByte, Char haben den selben aufbau. Auch sBytes haben nicht wirklich ein Bit belegt für das Vorzeichen. Der einzige unterschied ist die interne Verarbeitung, also der Startwert für die Rechenoperationen.Chars sind (wie alles andere im Computerspeicher auch) nummerische Werte, aber anders codiert als Zahlen. Deshalb kann man Strings nicht mit Longs gleichsetzen.
Und Stringvariablen und Longs sind Speicherintern auch das selbe. Es sind immer 4Bytes auch mit "dem selben Aufbau". in der Stringvariablen steht auch nur ein Zahlenwert.
Dann mußt du aber ach dazu sagen das das "sByte" (mit Vorzeichen) auch genau so codiert ist (was auch immer du damit meinst). Es stimmt schon. 8 Bit bleiben 8 Bit, aber das ist auch schon die einzige gemeinsamkeit. "sByte", "uByte" und Char sind einerseit das selbe (alle drei), andererseit haben sie nichts miteinander zu tun.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.
http://de.wikipedia.org/wiki/Char
Ich muß zugeben, um diese Dinge habe ich mich lange nicht mehr gekümmert (bestimmt vor 10 Jahren das letze mal aktiv), kann mich daher natürlich (wie bei allem
auch irren.Klar hast du auf eine Art recht es gibt ja auch manchmal (habe aber noch nicht wirklich kapiert warum) unsigned und signed Chars, auch Chars unterschiedlicher Länge. Eines bleibt aber, es sind "Zeichen".
Ich glaube der Sinn darin lag unter anderem, da es eine einfache Möglichkeit geben sollte, Zeichen ohne Umwege oder Umwandlung in ein "nummerische Variable" zu portieren.
Natürlich kann man schon deutlich sagen, das es nicht wirklich so ganz falsch ist. Char kann man natürlich schon zum rechen kleiner Werte nutzen. Einige Sprachen lassen sogar den Typ "Byte" weg und nutzen dafür Char, andere aber differenzieren hier genau.
http://www.dsdt.info/grundlagen/sprache/variablen.php
http://www.dpunkt.de/java/Die_Sprache_J ... va/29.html
Ich bleibe momentan noch bei der Meinung, weil ich es so mal gelernt habe und bisher auch immer nur bestätigt. Aber ich habe durch meine eigenen Fehler natürlich schon viel gelernt. Ich lasse mich als ohne sauer zu werden gerne beleeren. Diskutieren wir also weiter.
Ich denke aber, das es schon seinen sind hat, warum das Umwandeln eines Zahlenwerts in ein (Ascii-)Zeichen in fast allen Sprachen eine mit einer Funktion geschieht die Character() bzw. chr() oder Chr$() hast. Das der Datentyp "Zeichen" lautet, sollte wohl doch hoffentlich wirklich einen Sinn haben.
So, jetzt muß ich mich aber selbst erstmal stoppen *grins*
Lieber wieder etwas zurück zum Thema. Was natürlich stimmt, Char hin Char her, entweder sollte das Char in der Schleife und beim addieren gleich reagieren, also entweder signed oder unsigned sein. Das stimmt schon. Jetzt ist nur die Frage was richtig sein soll. Soweit ich mich erinnere sind Chars meist unsigned, aber offiziell unterschützt PB soweit ich weiß keine unsigned Variablen. Und "keine" sollte dann wohl auch "keine" bedeuten
Ist schon interessant was du da festgestellt hattest. Also unter Umständen könnte da doch ein Bug drinn sein. Bin ja mal gespannt was dabei rauskommt.
Grüßle
Toshy
[edit]
ps. Wollte nur noch mal sagen, das ich es ernst gemeint habe, das ich gerne was dazu lernen will, wenn m eine Auffassung nicht ganz korrekt ist.
