C-Strings: unsinged char* oder char*

[Gast]

hallo

Manchmal sieht man C-Strings definiert als unsinged char* oder char*. Was ist da eigentlich richtiger? Bzw. was sollte man für Strings verwenden?

[Gast]

Bei den allermeisten Compilern ist "char" das selbe wie "unsigned char".
Ich kenne keinen Compiler bei dem das anders wäre (auch wenn das im Standard nicht festgelegt ist).
Also kein Unterschied.

[mapel110]

signed oder unsigned / Vorzeichen oder kein Vorzeichen
http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html

Da würd ich eher vorher den Typ konvertieren, je nach dem, was man braucht.

[Grestorn]

Bei den allermeisten Compilern ist "char" das selbe wie "unsigned char".
Ich kenne keinen Compiler bei dem das anders wäre (auch wenn das im Standard nicht festgelegt ist).
Also kein Unterschied.

Ganz im Gegenteil.

char ist per Definition vorzeichenbehaftet!

Im täglichen Leben macht das aber keinen Unterschied, so lange man nicht mit den Zeichen im String Bitoperationen durchführt. Dann kann das signed stören.

[Coda]

char ist per Definition vorzeichenbehaftet!
Nein. Das ist im Standard undefiniert.

Wenn man mit 8-Bit-Werten rechnen will und portable Programme will dann sollte man "unsigned char" oder "signed char" schreiben. Für Strings ist es egal.

[Grestorn]

Nein. Das ist im Standard undefiniert.

Ich finde gerade keine freie ISO C99 Definition im Netz.

Aber ich bin mir zu 95% sicher, dass alle Integer-Typen in C (char, int, long) per Definition signed sind, wenn nichts explizit angegeben ist.

Von undefiniert weiß ich nichts und ich kann es mir ehrlich gesagt auch nicht vorstellen.

[Coda]

Ich hab recht, char ist eine Ausnahme. Da bin ich mir 100% sicher ;)

The C and C++ standards allows the character type char to be signed or unsigned, depending on the platform and compiler. Most systems, including x86 GNU/Linux and Microsoft Windows, use signed char, but those based on PowerPC and ARM processors typically use unsigned char.

Leaving the signedness of char up to the implementation had its drawbacks, though.

[Gast]

Das hängt immer von der Compilereinstellung ab. Beim Visual Studio hat man z.B. die Option, dass man das umstellen kann.

Weiter empfehle nicht signed bzw. unsigned char zu schreiben bzw. int bzw. unsigned int, sondern gleich einen Header machen, wo du ordentliche Typen mit typedef definierst z.B.:

int8, int16, int32, int64 statt signed char, short, int, long long
bzw.
uint8,uint16,uint32,uint64 statt unsigned char, unsigned short usw.

Dann noch byte statt uint8

Weil gerade die Länge von Integer, Long etc. ist je nach Plattform immer eine andere einmal abgesehen davon, dass unsigned long long viel zu schreiben ist und da verschwindet schnell einmal ein long und schon hängt sich das Programm nach 2 Jahren auf, wenn die Datenbank über 4GB groß wird ;-)

Das mit dem Byte ist auch praktisch und wird nicht umsonst in fast jeder aktuellen Programmiersprache verwenden.

Weiterer Tipp: Am Besten bei allem, was auf dem Stack liegt gar nicht mit 8 oder 16 Bit Variablen anfangen zu rechnen. Das macht nur Arbeit und langsamer ist es auch noch. Nur bei bools würde ich zur besseren Lesbarkeit wirklich noch bools verwenden, wenn man nicht wirklich jedes Stück Performance braucht.

[Coda]

bool ist bei Visual C++ auch 4 Bytes groß (KA ob bei 64-Bit 8 Bytes). Wohl aus Performancegründen. GCC verwendet als ich das letzte Mal geschaut habe ein Byte dafür.

[Ganon]

GCC verwendet als ich das letzte Mal geschaut habe ein Byte dafür.

Afaik gibt es dafür eine Compiler-Option. Zumindest in Xcode gibt es in den Build-Optionen einen Haken dafür.

[Chris Lux]

bool ist bei Visual C++ auch 4 Bytes groß (KA ob bei 64-Bit 8 Bytes). Wohl aus Performancegründen. GCC verwendet als ich das letzte Mal geschaut habe ein Byte dafür.
ist auch bei 64bit 4byte. nur die pointer typen sind auf 8byte gewachsen (und die size_types in der STL).

[Ectoplasma]

... (und die size_types in der STL)

Die size_type ist gewachsen, hmmm. Manchmal stehe ich ja auf dem Schlauch. Helf mir mal, aber ist die size_type nicht generisch? Was soll da wachsen, die ist doch abhängig vom Datentyp.

[PHuV]

Wer char im Sinne von Zeichendarstellungen ASCII 8 Bit verwenden will, sollte immer unsigned char verwenden. Ich habe da schon lustige Dinger bei der Pflege von altem Code entdeckt, da es dann bei >127 einen schönen Uberlauf gibt, und der kann zu sehr unschönen Effekten führen.

Bei den meisten Compiler, auf denen ich gearbeitet hatte (AIX, HP, SUN) ist der Default immer auf signed char eingestellt.

Afaik gibt es dafür eine Compiler-Option. Zumindest in Xcode gibt es in den Build-Optionen einen Haken dafür.

Yop, die meisten Compiler bieten die Möglichkeit, den Default entsprechend umzusetzen.

[PHuV]

Ich finde gerade keine freie ISO C99 Definition im Netz.



http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

[Chris Lux]

Die size_type ist gewachsen, hmmm. Manchmal stehe ich ja auf dem Schlauch. Helf mir mal, aber ist die size_type nicht generisch? Was soll da wachsen, die ist doch abhängig vom Datentyp.
warum sollte der abhaengig vom datentyp sein? bei einem vector ist das im endeffekt der index typ usw.... auf ner 64bit plattform passen ja auch mehr sachen in eine liste.

[Ectoplasma]

warum sollte der abhaengig vom datentyp sein? bei einem vector ist das im endeffekt der index typ usw.... auf ner 64bit plattform passen ja auch mehr sachen in eine liste.

Stimmt hast recht, habe die ganze Zeit an value_type gedacht :redface:
Siehste, stand doch aufm Schlauch ;)

[Coda]

Afaik gibt es dafür eine Compiler-Option. Zumindest in Xcode gibt es in den Build-Optionen einen Haken dafür.
Kann sein. Default war beim letzten Mal schauen halt 1 Byte. Ist ja auch nicht schlimm und hat auch seine Vorteile.