Ich bin ziemlich neu in C/C++, und ich versuche, einige Richtlinien zu folgen, die die Verwendung der definierten stdint.h definiert, wo möglich (uint8_t, etc anstelle von unsigned char).Warum verwenden Windows-API-Aufrufe, die mit Bytes arbeiten (z. B. 'recv'), char *, das standardmäßig signiert ist?
Es scheint jedoch, wenn Sie eine API aufrufen, die einen char* Puffer (wie recv) erwartet, müssen Sie den Typ verwenden, der API diktiert.
Was ich nicht verstehe ist, warum, wenn Sie Bytes lesen, würden Sie es nicht ohne Vorzeichen sein wollen, so erhalten Sie Werte zwischen 0 und 255 anstelle von -128 und 127
I Ich weiß nicht, ob das für die Implementierung spezifisch ist, aber ich habe nur char default zu signed gesehen.
Wird erwartet, dass Sie die Ergebnisse von Aufrufen wie diesem in eine unsigned char* oder uint8_t* umwandeln, damit Sie die höheren positiven Werte interpretieren können?
Da die Aufrufe nur einen Zeiger benötigen, nehme ich nicht an, dass die ursprünglichen Designer dachten, dass es so oder so von Bedeutung ist. –
Zuerst zu lernen ist, gibt es keine Sprache C/C++, aber nur die zwei ** verschiedenen ** Sprachen C und C++. Sagte, dass der C-Standard keine bestimmte Signed-Ness für 'char' definiert. Also das ist eine Windows-Angelegenheit. Und die WinAPI ist weit davon entfernt, den modernen C-Programmierstil zu verwenden; 'stdint.h' war nicht verfügbar, wenn es entworfen wurde. Und es spielt wahrscheinlich keine Rolle, ob 'char' für diese Funktionen signiert oder unsigniert ist. – Olaf
@Olaf Ah, ok. Es ist also implementierungsspezifisch? Und ich muss es nur interpretieren, macht aber Sinn für das, was ich schreibe? – Twicetimes