c++ - 为什么要担心签名类型的 >> 中的 'undefined behavior'？

Question

我的问题与 this one 有关并且将包含几个问题。

对我来说，对上述问题最明显的(意味着我会在我的代码中使用它)解决方案就是:

uint8_t x = some value;
x = (int8_t)x >> 7;

是的，是的，我听到你们所有人的声音......未定义的行为，这就是为什么我没有发布我的“解决方案”。

我有一种感觉(也许这只是我病态的想法)术语“未定义的行为”在 SO 上被过度使用，只是为了证明如果问题被标记为 c/c++，就可以否决某人。

所以 - 让我们(暂时)搁置 C/C++ 标准，想想日常生活/编程、真实的编译器实现以及它们为当代硬件生成的代码。

考虑到以下因素:

• 据我所知，我遇到的所有硬件都有不同的算术和逻辑移位指令。
• 我所知道的所有编译器都将 >>> 转换为有符号类型的算术移位和无符号类型的逻辑移位。
• 我不记得有任何编译器在 c/c++ 代码中使用 >>> 时发出类似 div 的低级指令(我们在这里不是在谈论运算符重载).
• 我知道的所有硬件都使用 U2。

那么...有什么(任何现代编译器、硬件)的行为与上述不同吗？简而言之，我是否应该担心右移带符号的值不会被转换为算术移位？

我的“解决方案”在许多平台上仅编译为一条低级指令，而其他平台则需要多条低级指令。您会在代码中使用什么？

请说实话;-)

Answer 1

Why worry about 'undefined behavior' in >> of signed type?

因为任何特定的未定义行为现在的定义有多好并不重要；关键是它可能会在未来的任何时候崩溃。您依赖于可能出于任何原因或没有原因随时优化(或未优化)的副作用。

此外，我不想在使用一开始就不应该使用的东西之前询问对许多不同编译器的实现有详细了解的人，所以我跳过了它。