铸造uint8_t至少有时不正确吗？

Getting a buffer into a stringstream in hex representation:

我不明白为什么有必要投uint8_t到unsigned（或写在评论，甚至unsigned char之前），而铸造只是为了int是不正确的。

据我所知，根本没有任何转换会导致将uint8_t解释为一种基本类型，它可以（必须是）变体的一部分，从而将其打印为字符。

但是铸造到int有什么问题？任何uint8_t的值应该始终适合int，所以转换看起来很简单。为什么sign-extension会使代码不正确（在注释中提到）？

UPD：

仅供参考，我想通了什么是在我提到的问题，谈到是signed char的情况下：

signed char num = -1; 
std::cout << std::hex << static_cast<unsigned int>(static_cast<unsigned char>(num));

这将被写为超过2 f在没有第二次演员的情况下。

点约2的补体系统似乎是不正确的，虽然，作为一个整体转换应适用于转换-1到unsigned <smth>，并且它遵循2的补数系统（即转换为例如uint8_t当结果应始终是255并因此被打印为0xff，甚至具有不同的位模式）。

来源

2017-07-03 ledonter

你是说在指针类型之间进行转换还是在这些类型的值之间进行转换？ –

如果缓冲区的类型可能是'char'（或其他非'unsigned'类型），答案和注释可能只是防御性的。您可以安全地将'uint8_t'转换为'int'而不会出现符号扩展问题。 – Cornstalks

@FrançoisAndrieux在这些类型的值之间进行转换（就像我在上面提到的问题的答案中所做的那样，即从'uint8_t'到'int'（'unsigned'）的转换） – ledonter

您无权输入uint8_t至int将产生与铸造uint8_t至unsigned int完全相同的值。测试uint8_t,0 ... 255所有可能值的简单循环将确认生成的字符串100％相同，并且假定所有实现必须支持值高于255的int值，则不可能有一些模糊的实现int的有限范围可能会导致问题。

来源

2017-07-03 19:41:20 hvd

而且你甚至可以做**转换**而无需**投射**。 –

@PeteBecker一般来说，是的。在这个问题的背景下，没有。当有几个函数（或者在这种情况下是运算符）重载时，即使您正在执行的转换是可以在其他上下文中隐式执行的转换，也可能需要强制转换以强制执行特定的重载。 – hvd

铸造uint8_t至少有时不正确吗？

回答

相关问题