Frage zu unsigned char

bobthebear

Hallo Leute,

ich habe eine Frage zum unsigned char, wie der Titel schon verrät :-).

Unsigned ändert den Wertebereich, das ist nachvollziehbar. Aber welchen Vorteil hat es ein unsigned char zu nutzen und damit 0 - 255 darstellen zu können, wenn doch die int. ASCII Tabelle nur von 0 - 127 reicht.

Und was macht diese Operation mit den unsigned char[].

unsigned char dings[16] = {""};

Vielen Dank für eure Hilfe.

(Hintergrund ist es, dass Ganze in ein String zu packen, aber erstmal will ich es richtig verstehen.

Verwende unsigned char, wenn Du es brauchst. Verwende char, wenn Du es brauchst. Verwende signed char, wenn Du es brauchst. Das sind übrigens 3 verschiedene Typen. Also, char ist nicht derselbe Typ wie signed char. char ist auch nicht unbedingt vorzeichenbehaftet. char benutzt man eigentlich nur in Verbindung mit Zeichenketten. unsigned char verwendet man oft für Binärdaten. ZB arbeiten viele Kryptographie-Bibliotheken mit unsigned char für binäre Schlüssel und Nachrichten etc.

Daumenregel:
Wenn's Dir um Zeichen und Zeichenketten geht ('a', 'x', "dings") nimm char.
Wenn Du "rechnen" willst, nimm signed char oder unsigned char -- je nachdem, was Dir besser passt.

bobthebear

Naja, die Funktion erwartet einen Datentyp BYTE gemäß der MSDN
(RegQueryValueEx). Daher komme ich da nicht drumherum.

Ich weiß jetzt auch, dass das {""} alle Bits der 16 Byte auf 0 setzt.

Wie kann ich es anstellen, dass ich daraus einen String mache? Einen passenden Konstruktor finde ich bei String nicht.

char buf[256];

sprintf(buf, "Ein String");

Aber das ist eher C... In C++ macht man das mit std::string:

std::string buf = "Ein String";

buf += " der immer laenger wird";
buf += ", lol";

... schrieb:

char buf[256];

sprintf(buf, "Ein String");
Aber das ist eher C... In C++ macht man das mit std::string:
std::string buf = "Ein String";

buf += " der immer laenger wird";
buf += ", lol";

Übrigens mit buf.c_str() kommst du dann auch an ein char * was die meisten WinAPI Funktionen erwarten.

Janjan

... schrieb:

Übrigens mit buf.c_str() kommst du dann auch an ein char * was die meisten WinAPI Funktionen erwarten.

Damit bekommt man einen const char-pointer. Deswegen auch **c_**str().

theliquidwave

unsigned char ist optimal zum speichern von Farbwerten
Man könnte meinen dass es dafür erfunden wurde.

Gruß

Janjan schrieb:

... schrieb:

buf.c_str()

Damit bekommt man einen const char-pointer. Deswegen auch **c_**str().

...und ich dachte immer, dass das c hier für die Sprache C und den in C üblichen nullterminierten "character strings" steht. Das c könnte natürlich auch einfach für character stehen... An const hatte ich dabei nie gedacht...

Nexus

Die Klasse std::stringstream hat zum Beispiel eine Methode str() , die einen String ( std::string ) zurückliefert. Als Analogie dazu scheint es mir naheliegend, für einen C-String ( const char* ) den Bezeichner c_str() zu wählen.

Ich weiß jetzt auch, dass das {""} alle Bits der 16 Byte auf 0 setzt.

Ist das standardkonform?
Sollte nicht nur das 1. Zeichen auf 0 gesetzt werden (= leerer String)?

hustbaer

mx schrieb:

Ich weiß jetzt auch, dass das {""} alle Bits der 16 Byte auf 0 setzt.

Ist das standardkonform?
Sollte nicht nur das 1. Zeichen auf 0 gesetzt werden (= leerer String)?

Ich weiss nicht ob es überhaupt standardkonform ist ein unsigned char Array mit einem String zu initialisieren.

Davon abgesehen...

Wenn du ein POD Array initialisierst, dann werden immer alle Elemente initialisiert. Elemente die man nicht angibt werden dabei auf Null initialisiert.
Man kann dabei sogar auch kein Element angeben:

int a[10] = { 1 }; // initialisiert a[0] mit 1, alle weiteren mit 0
int b[10] = {}; // initialisiert alle 10 Elemente mit 0
int c[10]; // uninitialisiert

p.S.: das gilt natürlich auch wenn man ein char Array mit einem String-Literal initialisiert, welches kürzer ist als das char Array.

SeppJ

hustbaer schrieb:

p.S.: das gilt natürlich auch wenn man ein char Array mit einem String-Literal initialisiert, welches kürzer ist als das char Array.

Das beantwortet dann auch deine Frage, ob die Null-Initialisierung mit "" standardkonform ist.

ipsec

SeppJ schrieb:

hustbaer schrieb:

p.S.: das gilt natürlich auch wenn man ein char Array mit einem String-Literal initialisiert, welches kürzer ist als das char Array.

Das beantwortet dann auch deine Frage, ob die Null-Initialisierung mit "" standardkonform ist.

Ich denke es geht speziell um das unsigned . "" ist ja vom Typ const char* ohne unsigned .