En lisant la réponse à la question suivanteLance uint8_t à int signé au moins parfois incorrect?
Getting a buffer into a stringstream in hex representation:
Je ne comprenais pas pourquoi il y a une nécessité de jeter uint8_t à unsigned (ou, comme il est écrit dans les commentaires, même unsigned char avant cela), alors que la coulée juste à int est incorrect. Si je comprends bien, aucune conversion n'aboutirait à interpréter uint8_t comme un type sous-jacent qui peut (doit?) Faire partie de 3 char variations et donc l'imprimer en tant que caractère.
Mais qu'est-ce qui ne va pas avec la conversion en int? N'importe quelle valeur uint8_t devrait toujours tenir dans int, donc la conversion semble être simple. Pourquoi sign-extension rendrait le code incorrect (mentionné dans les commentaires)?
UPD:
Juste pour référence, je me suis ce que l'on a parlé de la question dont j'ai parlé est un cas pour signed char:
signed char num = -1;
std::cout << std::hex << static_cast<unsigned int>(static_cast<unsigned char>(num));
Ce serait écrit que plus de 2 f s en l'absence du deuxième plâtre. Le point sur le système de complément à 2 semble être incorrect, car une conversion intégrale devrait s'appliquer pour convertir -1 à unsigned <smth>, et il adhère au système de complément à 2 (ie lors de la conversion en uint8_t le résultat devrait toujours être 255 et ainsi être imprimé comme 0xff, même ayant un modèle binaire différent).
Parlez-vous de la conversion entre les types de pointeurs ou de la conversion entre les valeurs de ces types? –
Les réponses et commentaires sont probablement juste défensifs dans les cas où le type du tampon pourrait être 'char' (ou un autre type non-'unsigned'). Vous pouvez sans risque transformer le 'uint8_t' en' int' sans problèmes d'extension de signe. – Cornstalks
@ FrançoisAndrieux conversion entre les valeurs de ces types eux-mêmes (comme cela est fait dans la réponse à la question que j'ai mentionné, à savoir la conversion de 'uint8_t' à' int' ('unsigned')) – ledonter