char vs. unsigned char
Peter Mairhofer
Spricht irgendwas dagegen fuer Strings prinzipiell "unsigned char" statt
"char" zu verwenden?
Wenn ich z.B. nicht nur ASCII verwende sondern z.B. ISO-8859 mit
Umlauten, dann verwende ich ja eigentlich die Zahlen bis 255 und nicht
-127 bis 127... Mit char waere es eben maschinenabhaengig ob sie von
-127 bis 127 oder von 0 bis 255 gehen.
Ebenso umgeht man das Problem mit ctype:
http://en.wikipedia.org/wiki/Ctype.h#Incorrect_usage
Ich wuerds irgendwie logischer finden strings immer als "unsigned char"
zu definieren, wundere mich aber dass alle Stringfunktionen immer "char"
akzeptieren.
LG
Peter
Markus Wichmann
Hysterisch so gewachsen :-) .
Und zwar schreibt der C-Standard nicht vor, dass ASCII verwendet wird.
Das Basic Execution Character Set muss nicht mal ASCII-kompatibel sein.
Und von ISO-8859 steht erst recht nix drin. In meinem Falle würde es
dein Programm umbringen, das verwenden zu wollen, denn mein Extended
Execution Character Set ist UTF-8.
Aber gut, du willst ja wenigstens einen ISO-Zeichensatz verwenden. Mein
Programmier-Professor denkt über so etwas gar nicht erst nach und
schreibt seine Programme grundsätzlich in CP-1252. *würg*
Das heißt also: Willst du ISO-8859 verwenden, musst du wissen (oder
nachprüfen), ob (oder dass) das System ISO-8859 versteht.
Außerdem ist doch extra für char eine Ausnahme gemacht worden:
Normalerweise ist ein Integer-Typ, an dem nicht dransteht, ob ein
Vorzeichen drin ist oder nicht, _immer_ vorzeichenbehaftet. Nur char ist
anders: Da kann es wenigstens manchmal sein, dass char vorzeichenlos
ist.
> LG
> Peter
HTH,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime
Peter Mairhofer
> Peter Mairhofer (6383...@gmx.net) schrieb:
>> Hi,
>>
>> Spricht irgendwas dagegen fuer Strings prinzipiell "unsigned char" statt
>> "char" zu verwenden?
>>
>> Wenn ich z.B. nicht nur ASCII verwende sondern z.B. ISO-8859 mit
>> Umlauten, dann verwende ich ja eigentlich die Zahlen bis 255 und nicht
>> -127 bis 127... Mit char waere es eben maschinenabhaengig ob sie von
>> -127 bis 127 oder von 0 bis 255 gehen.
>>
>> Ebenso umgeht man das Problem mit ctype:
>> http://en.wikipedia.org/wiki/Ctype.h#Incorrect_usage
>>
>> Ich wuerds irgendwie logischer finden strings immer als "unsigned char"
>> zu definieren, wundere mich aber dass alle Stringfunktionen immer "char"
>> akzeptieren.
>>
>
> Hysterisch so gewachsen :-) .
>
> Und zwar schreibt der C-Standard nicht vor, dass ASCII verwendet wird.
Ja das weiss ich.
Es geht darum, ein normales C Programm unter Posix mit LANG=de zu verwenden.
Also lange Rede kurzer Sinn: In diesem Fall gibt es keine Nachteile
unsigned char zu verwenden? Ist es sogar empfohlen?
Selbst wenn ich NUR ASCII verwenden wuerde: Gibt es dann irgendeinen
Nachteil fuer "unsigned char"?
LG
Peter
Georg Bauhaus
> Es geht darum, ein normales C Programm unter Posix mit LANG=de zu
> verwenden.
>
> Also lange Rede kurzer Sinn: In diesem Fall gibt es keine Nachteile
> unsigned char zu verwenden? Ist es sogar empfohlen?
>
> Selbst wenn ich NUR ASCII verwenden wuerde: Gibt es dann irgendeinen
> Nachteil fuer "unsigned char"?
Ich würde nachsehen, was die verwendeten compiler bieten
und dokumentieren, und weiter nicht darüber nachsinnen,
ob char (ein Datentyp für Zeichen...) ein Vorzeichen haben
wird und was das bedeutet.
Aber:
"The type char is always a distinct type from each of
signed char or unsigned char, even though its behavior
is always just like one of those two." (GCC 4)
Oder die Funktionen für die Handhabe von Text mit mehr
als 1<<7 möglichen Zeichen benutzen, wenn händisches UTF-8
nicht gut genug ist?
Den Quelltext selbst würde ich, sofern er international
normale Zeichen enthalten soll, in einer geeigneten,
seit den 90er Jahren verfürgbaren Obermenge von Zeichen
schreiben, also Unicode oder ISO 10646. Dann ist der
Quelltext wenigstens unzweideutig konvertierbar.
Rainer Weikusat
> Markus Wichmann wrote:
[...]
>>> Wenn ich z.B. nicht nur ASCII verwende sondern z.B. ISO-8859 mit
>>> Umlauten, dann verwende ich ja eigentlich die Zahlen bis 255 und
>>> nicht -127 bis 127... Mit char waere es eben maschinenabhaengig ob
>>> sie von -127 bis 127 oder von 0 bis 255 gehen.
[...]
>> Hysterisch so gewachsen :-) .
>>
>> Und zwar schreibt der C-Standard nicht vor, dass ASCII verwendet wird.
>> [...]
>
> Ja das weiss ich.
>
> Es geht darum, ein normales C Programm unter Posix mit LANG=de zu verwenden.
>
> Also lange Rede kurzer Sinn: In diesem Fall gibt es keine Nachteile
> unsigned char zu verwenden? Ist es sogar empfohlen?
Es gibt wenigstens einen Nachteil: Die gaengigen APIs benutzen alle
char * und den in letzter Zeit gestiegenem Warnungslaerm in gcc nach
zu vermuten, stehen 'vorzeichenlose Ganzzahltypen' auch noch auf der
Abschussliste der Leute, die schon vorzeichenbehaftete
Zweierkomplement-Arithmetik erledigt haben. Insbesondere ist unsigned
char nicht notwendigerweise kompatibel mit char und damit ist es
implementation defined ob ein cast von unsigned char * nach char * ein
definiertes Verhalten hat (Zeigerumwandlungen sind nur zulaessig,
falls die entsprechenden Basistypen kompatibel sind). Das ist
natuerlich fuer jegliche real existierende Hardware vollkommen
einerlei und tatsaechlich wird sogar ausdruecklich gefordert, dass
die Ausrichtungsanforderungen fur vorzeichenbehaftete und
vorzeichenlose gleichwertige Typen gleich sein sollen (6.2.5|6) und
die Werte im Schnittbereich identische Reprasentationen haben sollen
(6.2.5|9), aber der praktische Gummiparagraph ueber die
'aussergewoehnliche Situation', bei deren Auftreten das Verhalten
jedes Ausdrucks undefiniert wird, laesst sich auf alles anwenden.
Wie ja bereits geschrieben wurde, sollst ('shall') Du ausserdem nicht
ketzterischen Irrlehren anhaengen, dh zB internationale Normen
benutzen, die nicht von 'den Amis' geschrieben wurden, und diesen
tatsaechlich die Lufthoheit ueber 'Bit Nummer 8' streitig machen
wollten. } ist ein Buchstabe. '�' ist irgendsoein
Eingeborenen-Krikelkrakel mit dem zivilisierte Menschen sich nicht
abgeben ...
Marcel Müller
Peter Mairhofer wrote:
> Spricht irgendwas dagegen fuer Strings prinzipiell "unsigned char" statt
> "char" zu verwenden?
ja, die Compiler-Warnings, weil die ganze Standardbibliothek nur char*
verwendet. Meist reicht es auch nicht, per Compiler-Option den
Standard-Char-Typ passend zu schalten.
> Wenn ich z.B. nicht nur ASCII verwende sondern z.B. ISO-8859 mit
> Umlauten, dann verwende ich ja eigentlich die Zahlen bis 255 und nicht
> -127 bis 127... Mit char waere es eben maschinenabhaengig ob sie von
> -127 bis 127 oder von 0 bis 255 gehen.
Ja, ist aber Banane. Solange ein char nur als ein char interpretiert
wird, ist sein Integerwert vollkommen egal. Strenggenommen handelt es
sich bei dem Zeichen um einen Enumerationstyp mit einer
Codepage-abh�ngigen Belegungen. Erst wenn man anf�ngt munter zwischen
char und int umzuwandeln, wird das interessant.
Da wo man char wirklich als Integer mit begrentzem Werte- und
Platzbereich nutzt, kann man ja explizit unsigned char oder signed char
nehmen. Alle mir bekannten Compiler unterscheiden alle drei Typen.
Marcel
Stefan Reuther
> Spricht irgendwas dagegen fuer Strings prinzipiell "unsigned char" statt
> "char" zu verwenden?
Die Tatsache, dass dann keine der Funktionen aus <string.h> mehr nutzbar
ist.
> Wenn ich z.B. nicht nur ASCII verwende sondern z.B. ISO-8859 mit
> Umlauten, dann verwende ich ja eigentlich die Zahlen bis 255 und nicht
> -127 bis 127... Mit char waere es eben maschinenabhaengig ob sie von
> -127 bis 127 oder von 0 bis 255 gehen.
Also wenn ich Zeichen aus ISO-8859-1 verwende, dann verwende ich Zeichen
aus ISO-8859-1 und keine Zahlen. An den paar Stellen, wo man den
numerischen Wert braucht, kann man dann auch casten, und....
> Ebenso umgeht man das Problem mit ctype:
> http://en.wikipedia.org/wiki/Ctype.h#Incorrect_usage
....das Ding hab ich zumindest inzwischen im Wesentlichen im R�ckenmark,
so dass der '(unsigned char)'-Cast automatisch aus den Fingern kommt,
wenn ich 'toupper' o.�. tippe.
> Ich wuerds irgendwie logischer finden strings immer als "unsigned char"
> zu definieren, wundere mich aber dass alle Stringfunktionen immer "char"
> akzeptieren.
Ich mach das eigentlich ganz einfach: 'char', wenn es Zeichen sind,
'unsigned char' / 'signed char' (bzw. 'uint8_t' usw.) wenn es Zahlen sind.
Stefan