char ausgabe %c
-
Mr. N & elise: Auch wenn das mittlerweile nicht mehr der Diskussionspunkt ist: Bei Funktionen mit variabler Arumentleiste werden die Defaultpromotionen durchgeführt, ein char wird also hier als int übergeben, ein float als double, ein short als int usw usf. Und laut meiner Dokumentation gibt '%c' einen unsigned char aus, also ist der Cast auf char überflüssig (wenn ein char einen kleineren Wertebereich als int hat).
-
ich sehe grad, es ist compilerabhängig...
kann mir einer erklären, warum auf gleichem rechner, das studio den obigen code mit dem auswurf von mart macht, A mit strich auf 182, der cygwin aber tatsächlich auf der 193 das A mit strich fährt?
ich dachte, es ist rechnerabhängig...
[ Dieser Beitrag wurde am 05.04.2003 um 13:29 Uhr von elise editiert. ]
-
Es ist sogar abhängig von der verwendeten Schriftart.
Manche Schriften machen dann ein Herzchen oder sowas
-
@elise
das liegt wahrscheinlich daran, dass Cygwin ja ein POSIX/Unix Emulator ist und deswegen auch einen anderen Zeichensatz nutzt/emuliert
-
ich nehme an, der Visual nimmt den DOS-Konsolen-Zeichensatz und der Cygwin ISO-8859-1.
-
Bisher dachte ich immer das der ASCII Code einheitlich wäre ... wieso tauchen auf einmal solche unterschiede auf?
-
@mart
die lösung deiner probleme: nimm den cygwin
-
@elise: Nene, C coden dürfen die, die Kernel baun. (Und fürn Team bin ich zu jung *g*)
@Bitsy: Ein Prototyp ist schneller als ein #include - für den Compiler.
@Daniel E.: Darauf hatte ich schon hingewiesen :p
-
@elise: weil ich cygwin verwendet habe, bin ich ja komplett umgestiegen
- und hab sogar ut2003 (die demo) - mein lieblingsspiel
-
Original erstellt von Angel84:
Bisher dachte ich immer das der ASCII Code einheitlich wäre ... wieso tauchen auf einmal solche unterschiede auf?ASCII (ASCII heißt schon 'American Standard Code for Information Interchange'; nochmal ein Code dahinterzuschereiben kommt mir irgendwie komisch vor...), umfasst nur den Bereich von 0 bis 127. Der Rest ist eben irgendwas anderes.
Original erstellt von Mr. N:
@Daniel E.: Darauf hatte ich schon hingewiesen :pJa, mit einer Einschränkung (»zumindest aufm x86 meines wissens«), die überflüssig war und einen mitlesenden Neuling verwirren könnte.
-
@Mr.N: aber ein include ist wiederum schneller als ich, wenn ich mich an den Prototyp von printf erinnern muss. Da hätte ich spontan keine Ahnung, ob es mit int oder void anfängt. Und nach dem ersten fehlerhaften Compilieren ist der Zeitvorteil endgültig weg.
-
also den Bereich jenseits von 127 kenn ich als "erweiterten ASCII" .... Mit anderen Worten: Weshalb der Bereich jenseits von 127 so unterschiedlich is ist mir immernoch schleierhaft
@daniel e: Das passiert wenn man noch völlig verschlafen hier was postet ...
-
weil der ASCII Standard eben nur die ersten 7Bit des Codes festlegen. Ich glaub das liegt daran, dass das 8Bit früher für irgend welche anderen Dinge gebraucht wurde (bei Terminals kann man ja immer noch einstellen ob man 8Bit oder 7Bit übertragung haben will).
Der Rest wurde dann von anderen Standard hinzugefügt. Das hat mit dem Urspünglichen ASCII Standard nichts zu tun.
-
Original erstellt von Angel84:
also den Bereich jenseits von 127 kenn ich als "erweiterten ASCII" .... Mit anderen Worten: Weshalb der Bereich jenseits von 127 so unterschiedlich is ist mir immernoch schleierhaftAndere Länder, andere Sprachen, andere Buchstaben/Zeichen.
-
Original erstellt von kingruedi:
**weil der ASCII Standard eben nur die ersten 7Bit des Codes festlegen. Ich glaub das liegt daran, dass das 8Bit früher für irgend welche anderen Dinge gebraucht wurde (bei Terminals kann man ja immer noch einstellen ob man 8Bit oder 7Bit übertragung haben will).Der Rest wurde dann von anderen Standard hinzugefügt. Das hat mit dem Urspünglichen ASCII Standard nichts zu tun.**
thx ... das is ne Erklärung die ich auch nachvollziehen kann
