Hi leute! Ich hab ein problem, und zwar weis ich nciht was ein unsigned char ist! Wofür nutzte ich den? Hab den in einem Beipielprogramm, welches ich weiterverwerte, und weis nicht, wie ich damit umgehen soll! danke! mfg Jan
Am 18.08.2003 um 01:52:04 schrieb Jan Hendrik Berlin:
Hi leute! Ich hab ein problem, und zwar weis ich nciht was ein unsigned char ist! Wofür nutzte ich den? Hab den in einem Beipielprogramm, welches ich weiterverwerte, und weis nicht, wie ich damit umgehen soll!
Mit dem Schluesselwort unsigned wird das erste Bit als "echte" Stelle interprtiert und nicht als Vorzeichenbit: TYP WERTEBEREICH char, signed char -128 ... 127 unsigned char 0 ... 255 Wenn Du jetzt noch einen Blick in die ASCII-Tabelle wirfst, koennte Dir eine moegliche Verwendung dieses Datentypes in den Sinn kommen. Gruss Oli
danke! mfg Jan
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
Hi, On Mon, 18 Aug 2003, Oli Weiss wrote:
Mit dem Schluesselwort unsigned wird das erste Bit als "echte" Stelle interprtiert und nicht als Vorzeichenbit:
TYP WERTEBEREICH char, signed char -128 ... 127 unsigned char 0 ... 255
Also, um noch das letzte Quentchen zu diesem Thread beizutragen (nachdem Ralf und Phillip schon das wesentliche gesagt haben): "char", "signed char" und "unsigned char" sind drei _verschiedene_ Typen (!) . "char" ist als "signed char" oder "unsigned char" zu implementieren, welcher gewaehlt wird ist plattformabhaengig. Die Breite von char richtet sich nach der kleinsten addressierbaren Einheit. Ueblicherweise (aber nicht immer!) sind dies 8 Bit. (sh4 z.B. hat sizeof(char)==sizeof(int)==4). Wie diese 8 Bit interpretiert werden richtet sich nach der signedness von "char", i.e. ob's 0-255 oder -128-127 ist, ist plattformabhaengig. Man beachte, dass "int" gleich "signed int" ist, das gleiche gilt fuer "short", "long" und "long long", sowie vorraussichtlich fuer alle weiteren integer Typen die eventuell mal definiert werden. D.h. dass nur "char" einen Sonderstatus betreffend seiner signedness hat. So, Extrapunkte fuer den, der mir die signedness von bitfields herunterbeten kann ;-) (Ohne in den Standard zu gucken, also Phillip: du bist raus ;-) ) Ciao, Micha.
Hallo Jan, also hier mal ein kurzer überblick: - unsigned char: ist ein BYTE ohne Vorzeichen, also ein 0 bis 255 - char ist ein BYTE MIT Vorzeichen, also -128 bis 127 beide haben einen Wertebereich von 2^8 (sprich 2 hoch 8) Wofür braucht man den? - Nun einfach, wann immer man eine Variable benötigt, die einen Wertebereich von 2^8 nicht überschreitet. Natürlich kannst du auch einen anderen Datentypen mit einem größeren Wertebereich benutzen, aber manchmal ist es eben Praktisch ein BYTE zu benutzen. Ich entnehme deiner Frage, dass du noch nicht so richtig bewandert bist, deshalb einen kleinen Tipp: - Der Datentyp "int" ist Hardwareabhängig und wariiert je nach Prozessor und sollte daher gemieden werden. Wenn du mit 16 bit auskommst benutze besser: "short" oder "unsigned short", für 32-bit "long" oder "unsigned long" Gruss - Arndt Am Montag, 18. August 2003 01:52 schrieb Jan Hendrik Berlin:
Hi leute! Ich hab ein problem, und zwar weis ich nciht was ein unsigned char ist! Wofür nutzte ich den? Hab den in einem Beipielprogramm, welches ich weiterverwerte, und weis nicht, wie ich damit umgehen soll! danke! mfg Jan
On Mon, 2003-08-18 at 10:06, Arndt Stedler wrote:
Hallo Jan, also hier mal ein kurzer überblick: - unsigned char: ist ein BYTE ohne Vorzeichen, also ein 0 bis 255 - char ist ein BYTE MIT Vorzeichen, also -128 bis 127 beide haben einen Wertebereich von 2^8 (sprich 2 hoch 8) Nein. Es ist zwar wahr, dass auf den meisten Systemen ein char 8bit besitzt, doch ist nicht sichergestellt, dass ein char auf allen Systemen 8 Bit besitzt - Strenggenommen ist es jedoch blanker Zufall.
- Der Datentyp "int" ist Hardwareabhängig und wariiert je nach Prozessor und sollte daher gemieden werden.
Nein. Die Grössen aller Typen sind hardware- und Compiler-flag abhängig, Das trifft auf char ebenso zu wie auf short und int. Das einzige, worauf man sich verlassen kann. wäre: sizeof(char) <= sizeof(short) <= sizeof(int) Ralf
Ups, dass auch short mehr als 16 bit haben kann war mir nicht klar. Danke dafür. (Liegt aber daran, dass ich bisher nur mit Prozessoren (und kompilern) gearbeitet habe, die das so gehandhabt haben. --- Äh, nein, Aussnahme war der AD SHARK-Compiler. Liegt aber daran, dass der SHARK alles mit minimum 32 bit behandelt und man immer komische konstrukte bauen musste, wenn man byteweise arbeiten wollte) - Arndt Am Montag, 18. August 2003 11:30 schrieb Ralf Corsepius:
On Mon, 2003-08-18 at 10:06, Arndt Stedler wrote:
Hallo Jan, also hier mal ein kurzer überblick: - unsigned char: ist ein BYTE ohne Vorzeichen, also ein 0 bis 255 - char ist ein BYTE MIT Vorzeichen, also -128 bis 127 beide haben einen Wertebereich von 2^8 (sprich 2 hoch 8)
Nein. Es ist zwar wahr, dass auf den meisten Systemen ein char 8bit besitzt, doch ist nicht sichergestellt, dass ein char auf allen Systemen 8 Bit besitzt - Strenggenommen ist es jedoch blanker Zufall.
- Der Datentyp "int" ist Hardwareabhängig und wariiert je nach Prozessor und sollte daher gemieden werden.
Nein. Die Grössen aller Typen sind hardware- und Compiler-flag abhängig, Das trifft auf char ebenso zu wie auf short und int.
Das einzige, worauf man sich verlassen kann. wäre: sizeof(char) <= sizeof(short) <= sizeof(int)
Ralf
Am Montag, 18. August 2003 13:12 schrieb Arndt Stedler:
Ups, dass auch short mehr als 16 bit haben kann war mir nicht klar. Danke dafür. (Liegt aber daran, dass ich bisher nur mit Prozessoren (und kompilern) gearbeitet habe, die das so gehandhabt haben. --- Äh, nein, Aussnahme war der AD SHARK-Compiler. Liegt aber daran, dass der SHARK alles mit minimum 32 bit behandelt und man immer komische konstrukte bauen musste, wenn man byteweise arbeiten wollte)
- Arndt
Am Montag, 18. August 2003 11:30 schrieb Ralf Corsepius:
On Mon, 2003-08-18 at 10:06, Arndt Stedler wrote:
Hallo Jan, also hier mal ein kurzer überblick: - unsigned char: ist ein BYTE ohne Vorzeichen, also ein 0 bis 255 - char ist ein BYTE MIT Vorzeichen, also -128 bis 127 beide haben einen Wertebereich von 2^8 (sprich 2 hoch 8)
Nein. Es ist zwar wahr, dass auf den meisten Systemen ein char 8bit besitzt, doch ist nicht sichergestellt, dass ein char auf allen Systemen 8 Bit besitzt - Strenggenommen ist es jedoch blanker Zufall.
- Der Datentyp "int" ist Hardwareabhängig und wariiert je nach Prozessor und sollte daher gemieden werden.
Nein. Die Grössen aller Typen sind hardware- und Compiler-flag abhängig, Das trifft auf char ebenso zu wie auf short und int.
Das einzige, worauf man sich verlassen kann. wäre: sizeof(char) <= sizeof(short) <= sizeof(int)
Ralf
Jo, was unsigned char ist, ist mir jetzt klar! Danke!!!! mfg Jan
Hi Leute! Hab mir mal kylix3 installiert! Läuft baer nicht! Also, arbeiten kann ich damit soweit, nur wenn ich was kompilieren möchte, macht er ärger mit der time.h . Jo, auf meiner SuSE 7.3 Machiene hatte ich das ohne weiteres schonmal am laufen! Kennt einer den Fehler schon? mfg Jan
Hi, On Mon, 18 Aug 2003, Jan Hendrik Berlin wrote:
Hab mir mal kylix3 installiert! Läuft baer nicht!
Aha. Nun ja, der Bugfix wird wohl darin bestehen, es einfach zum Laufen zu bringen. Im Ernst: deine Bugbeschreibung ist reichlich duerftig. Was laeuft nicht?
Also, arbeiten kann ich damit soweit, nur wenn ich was kompilieren möchte, macht er ärger mit der time.h .
Was genau ist "der Aerger" mit time.h? Wie sind die Meldungen? Usw.
Kennt einer den Fehler schon?
Ich persoenlich habe mit Kylix3 noch nicht gearbeitet, deshalb kenne ich ihn nicht. Wenn du allerdings etwas praeziser fragen wuerdest, koennte man dir vielleicht trotzdem helfen. Ciao, Micha, der sechs Bier hatte.
Am Mon, 18 Aug 2003 22:10:16 +0200 schrieb Jan Hendrik Berlin :
Hi Leute! Hab mir mal kylix3 installiert! Läuft baer nicht! Also, arbeiten kann ich damit soweit, nur wenn ich was kompilieren möchte, macht er ärger mit der time.h . Jo, auf meiner SuSE 7.3 Machiene hatte ich das ohne weiteres schonmal am laufen! Kennt einer den Fehler schon?
Mögliche Lösung: in den Projekt-Optionen unter Verzeichnisse/Bedingungen mit der Reihenfolge der Einträge unter Include-Pfad experimentieren. Bei manchen hilft es z.B. den Eintrag /usr/include ganz nach vorn zu setzen. mfG, Jens -- ----- embesso - embedded software solutions ------ Hinter der Bahn 1 a | D 31162 Bad Salzdetfurth Tel: (+49)5064 - 950433 | Fax: (+49)5064 - 950459 http://www.embesso.com | jens.nixdorf@embesso.com
Hi Leute! Am Dienstag, 19. August 2003 13:09 schrieb Jens Nixdorf:
Am Mon, 18 Aug 2003 22:10:16 +0200 schrieb Jan Hendrik Berlin :
Hi Leute! Hab mir mal kylix3 installiert! Läuft baer nicht! Also, arbeiten kann ich damit soweit, nur wenn ich was kompilieren möchte, macht er ärger mit der time.h . Jo, auf meiner SuSE 7.3 Machiene hatte ich das ohne weiteres schonmal am laufen! Kennt einer den Fehler schon?
nebenbei bemerkt: Daß Betreff falsch eingegliedert ist, dafür kann ich nichts. Ich habe das selbe Problem unter SuSE 8.2 Kylix bleibt beim öffnen von Dateien oder speichern im Dateifenster einfach hängen. so daß man da nur noch mit einem kill von Kylix wider raus kommt, oder wenn man Glück hat und sehr lange wartet
Mögliche Lösung: in den Projekt-Optionen unter Verzeichnisse/Bedingungen mit der Reihenfolge der Einträge unter Include-Pfad experimentieren. Bei manchen hilft es z.B. den Eintrag /usr/include ganz nach vorn zu setzen.
Das habe ich auch schon alles überprüft, und war von der Installation von Kylix alles richtig eingetragen. Ich habe irgend wo in der Mailingliste gelesen (weiss aber nicht mehr wo),mit: strace -fo /dev/null /usr/local/kylix3/bin/startdelphi & in einer Console gestartet würde alles funtionieren. Das trifft zwar auf den von mir oben genannten Fehler zu, Dateifenster kann man öffnen und schliessen, aber ein normales Arbeiten ist nicht möglich. Laut Aussage in der entsprechenden Mailingliste schiebt Borland den schwarzen Peter dem neuen Kernel zu und das selbe umgekehrt. Ich kann nur sagen daß ich kein Programm kenne, das nicht zu SuSE gehört und auch schon so alt ist und älter ist als Kylix 3 professional, solche Probleme keines macht. Meine Meinung ist, solange Borland kein Upgrade zur ferfügung stellt, wird Kylix 3 niemals ordentlich laufen auf einem SuSE 8.2. Auch auf dem neuen 2.4.21-4 Kernel läuft es nicht. Zu SuSE 8.0 u. 8.1 kann ich nichts dazu sagen, wiel ich es in dieser Zeit nicht installiert hatte (zu wenig Zeit in der damaligen Zeit). Nach meinen Reserchen die ich bis her schon alle angestellt habe, gibt es nur die Möglichkeit, altes SuSE und Kylix 3 oder auf Kylix zu verzichten. Schade, ich hätte Kylix 3 auch gerne am laufen. Viele Grüsse Heinz
Hall Heinz Dittmar, hallo leute! Also erstmal zu Heinz Dittmar, bitte lies dich deine mails nochmal, bevor du sie in die weite Welt hinaus schickst! So abgehackte Sätze lesen sich recht schwer! Ich habe ein anderes Problem!!! Also, alles läuft wunderbar! Ich möchte eigentlich nur die C++ Versio nutzen..., aber hab auch mal bei Dephi reingeschaut! Mein Problem tritt bei der Version mit C++ auf, also wenn ich bcblin oder wie das heißt starte! Ich wollte einfach mal zum testen ein "leeren" Button als Programm starten! So, also füge ich da son Button ein, und mache den testlauf... Normalerweise sieht man da ja nun ein Fenster, mit einem Button, wenn man drauf clickt, passiert halt nichst! do kenne ich es von Windows, und hab es auch mit Der Delphi Version getestet! Jo, das Fenster erschein nun also nicht, und er meldet einige Fehler in der time.h! Ich hoffe das gnügt als Fehlerbeschreibung! mfg Jan Am Dienstag, 19. August 2003 17:06 schrieb Heinz Dittmar:
Hi Leute!
Am Dienstag, 19. August 2003 13:09 schrieb Jens Nixdorf:
Am Mon, 18 Aug 2003 22:10:16 +0200 schrieb Jan Hendrik Berlin :
Hi Leute! Hab mir mal kylix3 installiert! Läuft baer nicht! Also, arbeiten kann ich damit soweit, nur wenn ich was kompilieren möchte, macht er ärger mit der time.h . Jo, auf meiner SuSE 7.3 Machiene hatte ich das ohne weiteres schonmal am laufen! Kennt einer den Fehler schon?
nebenbei bemerkt: Daß Betreff falsch eingegliedert ist, dafür kann ich nichts.
Ich habe das selbe Problem unter SuSE 8.2 Kylix bleibt beim öffnen von Dateien oder speichern im Dateifenster einfach hängen. so daß man da nur noch mit einem kill von Kylix wider raus kommt, oder wenn man Glück hat und sehr lange wartet
Mögliche Lösung: in den Projekt-Optionen unter Verzeichnisse/Bedingungen mit der Reihenfolge der Einträge unter Include-Pfad experimentieren. Bei manchen hilft es z.B. den Eintrag /usr/include ganz nach vorn zu setzen.
Das habe ich auch schon alles überprüft, und war von der Installation von Kylix alles richtig eingetragen.
Ich habe irgend wo in der Mailingliste gelesen (weiss aber nicht mehr wo),mit: strace -fo /dev/null /usr/local/kylix3/bin/startdelphi & in einer Console gestartet würde alles funtionieren. Das trifft zwar auf den von mir oben genannten Fehler zu, Dateifenster kann man öffnen und schliessen, aber ein normales Arbeiten ist nicht möglich. Laut Aussage in der entsprechenden Mailingliste schiebt Borland den schwarzen Peter dem neuen Kernel zu und das selbe umgekehrt. Ich kann nur sagen daß ich kein Programm kenne, das nicht zu SuSE gehört und auch schon so alt ist und älter ist als Kylix 3 professional, solche Probleme keines macht. Meine Meinung ist, solange Borland kein Upgrade zur ferfügung stellt, wird Kylix 3 niemals ordentlich laufen auf einem SuSE 8.2. Auch auf dem neuen 2.4.21-4 Kernel läuft es nicht. Zu SuSE 8.0 u. 8.1 kann ich nichts dazu sagen, wiel ich es in dieser Zeit nicht installiert hatte (zu wenig Zeit in der damaligen Zeit). Nach meinen Reserchen die ich bis her schon alle angestellt habe, gibt es nur die Möglichkeit, altes SuSE und Kylix 3 oder auf Kylix zu verzichten. Schade, ich hätte Kylix 3 auch gerne am laufen.
Viele Grüsse
Heinz
Am Tue, 19 Aug 2003 18:42:34 +0200 schrieb Jan Hendrik Berlin :
Hall Heinz Dittmar, hallo leute! Also erstmal zu Heinz Dittmar, bitte lies dich deine mails nochmal, bevor du sie in die weite Welt hinaus schickst! So abgehackte Sätze lesen sich recht schwer!
Das finde ich ganz schön mutig! Wer im Glashaus sitzt... mfG, Jens
Am Tue, 19 Aug 2003 18:42:34 +0200 schrieb Jan Hendrik Berlin :
Ich hoffe das gnügt als Fehlerbeschreibung!
Nein, tut es nicht. Es fehlt, welche Kylix-Version Du auf welchem Linux-System laufen lassen willst. Da gibt es nämlich durchaus Unterschiede. Die Open Edition von Kylix verhält sich anders als die Professional, und unter SuSE 8.0 verhalten sich beide Versionen wiederum anders als unter SuSE 8.2. mfG, Jens
Moin! Am Die, 2003-08-19 um 17.06 schrieb Heinz Dittmar:
Ich habe das selbe Problem unter SuSE 8.2
Nutze ich auch
Kylix bleibt beim öffnen von Dateien oder speichern im Dateifenster einfach hängen. so daß man da nur noch mit einem kill von Kylix wider raus kommt, oder wenn man Glück hat und sehr lange wartet
Das habe ich auch schon alles überprüft, und war von der Installation von Kylix alles richtig eingetragen.
Ich habe irgend wo in der Mailingliste gelesen (weiss aber nicht mehr wo),mit: strace -fo /dev/null /usr/local/kylix3/bin/startdelphi & in einer Console gestartet würde alles funtionieren.
Hier sind einige "tricks" gesammelt. http://www.kylixforum.de/forum/viewforum.php?f=11&sid=c2f3f016a235c81dae5d4c25f3f69fd8 Einen Patch gibt es auch.
Meine Meinung ist, solange Borland kein Upgrade zur ferfügung stellt, wird Kylix 3 niemals ordentlich laufen auf einem SuSE 8.2. Auch auf dem neuen 2.4.21-4 Kernel läuft es nicht. Zu SuSE 8.0 u. 8.1 kann ich nichts dazu sagen, wiel ich es in dieser Zeit nicht installiert hatte (zu wenig Zeit in der damaligen Zeit). Nach meinen Reserchen die ich bis her schon alle angestellt habe, gibt es nur die Möglichkeit, altes SuSE und Kylix 3 oder auf Kylix zu verzichten. Schade, ich hätte Kylix 3 auch gerne am laufen.
Kylix/Delphi habe ich hier zumlaufen gekriegt. Ziemlich lange dran rumgebastelt. Selbst mit Patch. Kylix/c++ gibt beim comiplieren des leeren Fensters schon eine ellenlange Fehlerliste aus. Hab ich dann gleich abgebrochen - keinen Bock mehr. Obwohl ich C++ gerne hätte, aber irgendwie ist mir die Zeit zu schade. Meine Meinung ist das Borland ein ganz klein wenig misslungen. Support - nicht wirklich. Elchtest mässig...
Moin,
* Ralf Corsepius
Das einzige, worauf man sich verlassen kann. wäre: sizeof(char) <= sizeof(short) <= sizeof(int)
Wie ich gerade gelesen habe, fordert ISO C Mindestgrößen, char 8 Bit, short und int 16 Bit, long 32 Bit. Thorsten -- Violence is the last refuge of the incompetent - Isaac Asimov
On Wed, 2003-08-20 at 22:40, Thorsten Haude wrote:
Moin,
* Ralf Corsepius
[2003-08-18 11:30]: Das einzige, worauf man sich verlassen kann. wäre: sizeof(char) <= sizeof(short) <= sizeof(int)
Wie ich gerade gelesen habe, fordert ISO C Mindestgrößen, char 8 Bit, short und int 16 Bit, long 32 Bit.
Ist ja schön für ISO-C (Ich habe keine Kopie des ISO-C/C99 oder C89), nur sieht die Praxis anders aus. Beispiele: 1. Auf DSPs gilt oft sizeof(char) == sizeof(short) == sizeof(int) = 1 == 32bit. z.B.: TI TMS320C[34]x-Prozessoren (als c4x|c3x in gcc-2.95 und tic3x/4x CPU in gcc-3.x zu finden) 2. Auf 16-bit-Systemen gilt oft sizeof(char) = 1 == 8bit sizeof(short) == sizeof(int) = 2 == 16bit z.B.: Hitachi h83xx (als h8300 in gcc zu finden) IIRC, gehören der C6502 (C64-Prozessor) und der Z80 ebenfalls in diese Kategorie von Prozessoren. 3. Es gibt historische Systeme (Heute praktisch ohne Belang), die mit weniger als 8bit pro char gearbeitet haben (z.B. 6bit/7bit-Systeme). IIRC, gehören frühe PDPs dazu. Ralf
Hi, On 21 Aug 2003, Ralf Corsepius wrote:
Wie ich gerade gelesen habe, fordert ISO C Mindestgrößen, char 8 Bit, short und int 16 Bit, long 32 Bit.
Ist ja schön für ISO-C (Ich habe keine Kopie des ISO-C/C99 oder C89), nur sieht die Praxis anders aus.
Beispiele:
1. Auf DSPs gilt oft sizeof(char) == sizeof(short) == sizeof(int) = 1 == 32bit.
Womit uebrigens alle obigen Forderungen erfuellt sind, ist also kein Gegenbeispiel (== ist insbes. auch <=, und "mind. 8 Bit" wird auch von "32 Bit" erfuellt). Davon abgesehen hast du durchaus recht. DSP-C ist nicht immer ISO-C konform, aber meistens eigentlich schon, bis auf ein paar extension, wie spezielle Vektor-Typen und so.
2. Auf 16-bit-Systemen gilt oft sizeof(char) = 1 == 8bit sizeof(short) == sizeof(int) = 2 == 16bit
Auch dies erfuellt obige Bedingungen. int darf 16 Bit sein. Nur long muss mind. 32 bit haben.
3. Es gibt historische Systeme (Heute praktisch ohne Belang), die mit weniger als 8bit pro char gearbeitet haben (z.B. 6bit/7bit-Systeme).
Ja gut. So'n alter Schrott wird natuerlich nicht in einer Sprache programmiert die unserem heutigen C aehnlich ist ;-) Historisch interessant aber nicht relevant fuer ne Diskussion ueber portable Programmierung ;) Ciao, Micha.
Unterlass bitte den TOFU (näheres unter http://learn.to/quote), das bringt
dir keine Freunde ein.
Arndt Stedler
- Der Datentyp "int" ist Hardwareabhängig und variiert je nach Prozessor und sollte daher gemieden werden. Wenn du mit 16 bit auskommst benutze besser: "short" oder "unsigned short", für 32-bit "long" oder "unsigned long"
Falsch! Der ISO C Standard definiert nur Mindestlängen für Datentypen. Präziser definiert die Datentypen das zur jeweiligen Plattform gehörende ABI. So gilt z.B. für Linux auf AMD64 (Opteron, Athlon64): char 8 Bit short 16 Bit int 32 Bit long 64 Bit Datentypen wie int kann man sehr wohl verwenden, wenn es vorrangig um schnelle Verarbeitung geht. Wer Datentypen exakter Länge benötigt, verwendet unter ISO C99 die in inttypes.h definierten Typen. Dort findet man dann z.B. int8_t, int16_t oder int32_t. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de SuSE Linux AG Privat: philipp.thomas@t-link.de
On Mon, 18 Aug 2003, Jan Hendrik Berlin wrote:
Hi leute! Ich hab ein problem, und zwar weis ich nciht was ein unsigned char ist! Wofür nutzte ich den? Hab den in einem Beipielprogramm, welches ich weiterverwerte, und weis nicht, wie ich damit umgehen soll! danke! mfg Jan
Hallo Jan, Normalerweise hat ja char einen Wertebereich zwischen minus 127 und plus 128 - dieser Bereich wird auch 'signed char' gennant. 'char' wird automatisch als 'signed char' betrachtet bzw. 'char' oder 'signed char' ist das gleiche. Jetzt gibt es aber auch noch eine Möglichkeit, den Wertebereich von char zu erweitern - das geht mit 'unsigned char'. Dann hast du einen Wertebereich zwischen 0 und 255. Ich hoffe, ich konnte dir damit helfen
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
Gruß, Daniel -- Daniel Feist (clusterix.perl@gmx.de)
Moin,
* Daniel Feist
Normalerweise hat ja char einen Wertebereich zwischen minus 127 und plus 128 - dieser Bereich wird auch 'signed char' gennant. 'char' wird automatisch als 'signed char' betrachtet bzw. 'char' oder 'signed char' ist das gleiche.
Das gilt nur für die anderen Ganzzahlentypen. Der Wertebereich von 'char' ist vom Compilerbauer frei wählbar und kann 'signed char', 'unsigned char' oder wie ich gerade lese eine Mischform sein. "Mischform?" fragt Ihr Euch jetzt: Type char may be a "pseudo-unsigned" integral type - that is, it can contain only nonnegative values, but it is treated as if it were a signed type when performing the usual unary conversions. (Samuel P. Harbison, Guy L. Steele: C: A Reference Manual)
Jetzt gibt es aber auch noch eine Möglichkeit, den Wertebereich von char zu erweitern - das geht mit 'unsigned char'.
s/erweitern/verschieben/
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
Einfach löschen, was Du nicht mehr brauchst. Thorsten -- It is exactly because markets are amoral that we cannot leave the allocation of resources entirely to them. - George Soros
On Wed, 20 Aug 2003, Thorsten Haude wrote:
Moin,
* Daniel Feist
[2003-08-18 10:12]: Normalerweise hat ja char einen Wertebereich zwischen minus 127 und plus 128 - dieser Bereich wird auch 'signed char' gennant. 'char' wird automatisch als 'signed char' betrachtet bzw. 'char' oder 'signed char' ist das gleiche.
Das gilt nur für die anderen Ganzzahlentypen. Der Wertebereich von 'char' ist vom Compilerbauer frei wählbar und kann 'signed char', 'unsigned char' oder wie ich gerade lese eine Mischform sein.
"Mischform?" fragt Ihr Euch jetzt: Type char may be a "pseudo-unsigned" integral type - that is, it can contain only nonnegative values, but it is treated as if it were a signed type when performing the usual unary conversions.
(Samuel P. Harbison, Guy L. Steele: C: A Reference Manual)
Jetzt gibt es aber auch noch eine Möglichkeit, den Wertebereich von char zu erweitern - das geht mit 'unsigned char'.
s/erweitern/verschieben/
Hallo Thorsten,
Genau so ist das - es ist ja so, dass da mit signed und unsigned nicht nur
bei char so ist, sodern auch bei anderen - hier eine kleine Tabelle:
char, signed char 1 Byte == 8 Bit -128 +127
unsigned char 1 Byte == 8 Bit 0 255
short, signed short 2 Byte == 16 Bit -32768 +32767
unsigned short 2 Byte == 16 Bit 0 65535
int, signed int 4 Byte == 32 Bit -2147483648 +2147483648
unsigned int 4 Byte == 32 Bit 0 4294967295
long, signed long 4 Byte == 32 Bit -2147483648 +2147483648
unsigned long 4 Byte == 32 Bit 0 4294967295
Hier ein simples Programmbeispiel:
#include
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
Einfach löschen, was Du nicht mehr brauchst.
Thorsten -- It is exactly because markets are amoral that we cannot leave the allocation of resources entirely to them. - George Soros
Gruß, Daniel -- Daniel Feist (clusterix.perl@gmx.de)
Hi, On Wed, 20 Aug 2003, Daniel Feist wrote:
Das gilt nur für die anderen Ganzzahlentypen. Der Wertebereich von 'char' ist vom Compilerbauer frei wählbar und kann 'signed char', 'unsigned char' oder wie ich gerade lese eine Mischform sein.
"Mischform?" fragt Ihr Euch jetzt: Type char may be a "pseudo-unsigned" integral type - that is, it can contain only nonnegative values, but it is treated as if it were a signed type when performing the usual unary conversions.
(Samuel P. Harbison, Guy L. Steele: C: A Reference Manual)
Ist aber Unsinn. 6.2.5 #15: The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char.35) NB der letzten Halbsatz. Das Verhalten von 'char' muss exakt mit entweder 'signed char' oder 'unsigned char' uebereinstimmen. Nix Mischform.
Genau so ist das - es ist ja so, dass da mit signed und unsigned nicht nur bei char so ist, sodern auch bei anderen - hier eine kleine Tabelle:
char, signed char 1 Byte == 8 Bit -128 +127
Nein, du hast nicht verstanden worum es ging. 'char' ist ein _dritter_ Typ, neben 'signed char' und 'unsigned char'. Seine Attribute sind gleich denen von _entweder_ 'signed char' _oder_ 'unsigned char'. Das ist ein Unterschied zu den anderen integer Typen, wo 'xx' implizit die signed Variante ist (xx == {short int,int,long,long long}), d.h. fuer diese gibt es nur jeweils zwei Varianten. Ein char hat auch nicht immer 8 Bit. Genau wie die Breiten aller anderen von dir angegebenen Typen nicht festgelegt ist. Insbesondere ist "long" sehr oft auch 64bit gross. Ciao, Micha.
Moin,
* Michael Matz
Das gilt nur für die anderen Ganzzahlentypen. Der Wertebereich von 'char' ist vom Compilerbauer frei wählbar und kann 'signed char', 'unsigned char' oder wie ich gerade lese eine Mischform sein.
"Mischform?" fragt Ihr Euch jetzt: Type char may be a "pseudo-unsigned" integral type - that is, it can contain only nonnegative values, but it is treated as if it were a signed type when performing the usual unary conversions.
(Samuel P. Harbison, Guy L. Steele: C: A Reference Manual)
Ist aber Unsinn. 6.2.5 #15:
Wenn Du das so deutlich beurteilst, solltest Du vielleicht die Quelle nennen. Es ist gut möglich, daß das C:ARM sich irrt, aber aus irgendeinem Grund werden sie das so beschrieben haben. Thorsten -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Hi, On Wed, 20 Aug 2003, Thorsten Haude wrote:
(Samuel P. Harbison, Guy L. Steele: C: A Reference Manual)
Ist aber Unsinn. 6.2.5 #15:
Wenn Du das so deutlich beurteilst, solltest Du vielleicht die Quelle nennen.
Err. Hab ich ja. Du hast sie sogar noch zitiert: 6.2.5 #15. Natuerlich im ISO/IEC 9899:1999 .
Es ist gut möglich, daß das C:ARM sich irrt, aber aus irgendeinem Grund werden sie das so beschrieben haben.
Entweder sie irren sich, oder du interpretierst zuviel hinein. Ich kenne C:ARM nicht, kenne also auch den Kontext der von dir zitierten Stelle nicht, kann dies also nicht wirklich beurteilen. Ciao, Micha.
Moin,
* Michael Matz
On Wed, 20 Aug 2003, Thorsten Haude wrote:
(Samuel P. Harbison, Guy L. Steele: C: A Reference Manual)
Ist aber Unsinn. 6.2.5 #15:
Wenn Du das so deutlich beurteilst, solltest Du vielleicht die Quelle nennen.
Err. Hab ich ja. Du hast sie sogar noch zitiert: 6.2.5 #15.
Das hätte ich an der Kapitelnummer erkennen sollen?
Natuerlich im ISO/IEC 9899:1999 .
Ach so. Gibt's die im Netz?
Es ist gut möglich, daß das C:ARM sich irrt, aber aus irgendeinem Grund werden sie das so beschrieben haben.
Entweder sie irren sich, oder du interpretierst zuviel hinein.
Naja, so viel kann man da nicht falsch interpretieren. Es sind drei Punkte, erster und zweiter sind 'signed char' und 'unsigned char', den dritten habe ich zitiert. Die Brüder scheinen da einfach falsch zu liegen. Thorsten -- It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
Thorsten Haude
Natuerlich im ISO/IEC 9899:1999 .
Ach so. Gibt's die im Netz?
Ja, aber nicht kostenlos. Wenn ich mich recht entsinne, kostet die PDF Version rund $20. Und wenn du meinst, das sei teuer, dann solltest du dir mal den Preis für die gedruckte Version ansehen (einige hundert Dollar). Philipp
Moin,
* Daniel Feist
On Wed, 20 Aug 2003, Thorsten Haude wrote:
* Daniel Feist
[2003-08-18 10:12]: Genau so ist das - es ist ja so, dass da mit signed und unsigned nicht nur bei char so ist, sodern auch bei anderen
Nein, eben nicht. Der Typ 'char' hat eine ganz besondere Rolle. Nur bei den anderen integralen Typen ist <typ> == signed <typ>. Die Längen, die Du anschließend in der Tabelle aufführst, sind auch nur Zufall, die Typen können auch eine andere Länge haben. Es gibt zwar einige Regeln, aber nur Mindestgrößen: (signed) int: INT_MIN...INT_MAX unsigned int: 0...UINT_MAX Mit INT_MIN <= -32767, INT_MAX >= 32767, UINT_MAX >= 65535 Und so weiter, mit char >= 8 Bit, short >= 16 Bit, long >= 32 Bit. Außerdem gibt es noch CHAR_BIT, das die Anzahl Bits für den Typ char enthält. (Kann ich nicht fein aus der Referenz abtippen?)
printf("a = %c\n", b); /*Überrascht?*/
Nein.
Wichtig ist, dass der richtige Datentyp mit %c dem Compiler richtig gesagt wird - dann weiß dieser, dass er die ASCII-Tabelle nehmen soll - hätte man eben %d genommen, wäre 65 richtig ausgegen worden.
Richtig ist, daß Du printf() mitteilst, wie es den Parameter interpretieren soll. Du kannst auch einen Pointer als Integral interpretieren, kein Problem.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
Einfach löschen, was Du nicht mehr brauchst.
Hallo? Jemand zuhause? Thorsten -- Calvin: "Who can fathom the feminine mind?" Hobbes: "I like `em anyway"
Jan Hendrik Berlin
Ich hab ein problem, und zwar weis ich nicht was ein unsigned char ist! Wofür nutzte ich den?
Dann besorg dir erst einmal schleunigst ein vernünftiges Buch über C, denn für das Programmieren wirst du um die Kenntnis der fundamentalen Datentypen nicht drumherum kommen. Ausserdem empfehle ich dann eher die Newsgroup de.comp.lang.c statt dieser Mailingliste. Philipp
participants (11)
-
Andre
-
Arndt Stedler
-
Daniel Feist
-
Heinz Dittmar
-
Jan Hendrik Berlin
-
Jens Nixdorf
-
Michael Matz
-
Oli Weiss
-
Philipp Thomas
-
Ralf Corsepius
-
Thorsten Haude