面试问题中的这个位操作代码有什么问题？
我正在查看此页面： http://www.devbistro.com/ tech-interview-questions/Cplusplus.jsp，并且不明白这个问题：
以下代码可能存在什么问题？
长值； //一些东西 值&=0xFFFF；注意：向候选人提示他们正在开发的基础平台。如果此人仍然没有发现代码有任何问题，则说明他们没有 C++ 经验。
有人可以详细说明一下吗？
谢谢！
I was having a look over this page: http://www.devbistro.com/tech-interview-questions/Cplusplus.jsp, and didn't understand this question:
What’s potentially wrong with the following code?
long value; //some stuff value &= 0xFFFF;Note: Hint to the candidate about the base platform they’re developing for. If the person still doesn’t find anything wrong with the code, they are not experienced with C++.
Can someone elaborate on it?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这里的几个答案指出，如果
int的宽度为 16 位，则0xFFFF为负数。这不是真的。0xFFFF永远不会是负数。十六进制文字由以下类型中第一个足以容纳它的类型表示：
int、unsigned int、long和 <代码>无符号长。如果
int的宽度为16位，则0xFFFF大于int可表示的最大值。因此，0xFFFF是unsigned int类型，保证其足够大以表示0xFFFF。当执行通常的算术转换来评估
&时，unsigned int会转换为long。 16 位unsigned int到long的转换是明确定义的，因为由 16 位unsigned int表示的每个值也可以表示32 位long。不需要符号扩展，因为初始类型没有符号，并且使用
0xFFFF的结果与使用0xFFFFL的结果相同。或者，如果
int比 16 位宽，则0xFFFF的类型为int。它是一个带符号的正数。在这种情况下，两个操作数都是有符号的，并且long具有更高的转换等级，因此int通过通常的算术转换再次提升为long。正如其他人所说，您应该避免对有符号操作数执行按位运算，因为数字结果取决于符号的表示方式。
除此之外，这段代码没有什么特别的错误。我认为这是一个风格问题，即
value在声明时未初始化，但这可能是一个挑剔级别的注释，并且取决于//some stuff的内容code> 被省略的部分。为了获得更好的可移植性，最好使用固定宽度的整数类型（如 uint32_t ）而不是 long ，但这实际上也取决于您正在编写的代码和内容你的基本假设是。
Several answers here state that if an
inthas a width of 16 bits,0xFFFFis negative. This is not true.0xFFFFis never negative.A hexadecimal literal is represented by the first of the following types that is large enough to contain it:
int,unsigned int,long, andunsigned long.If
inthas a width of 16 bits, then0xFFFFis larger than the maximum value representable by anint. Thus,0xFFFFis of typeunsigned int, which is guaranteed to be large enough to represent0xFFFF.When the usual arithmetic conversions are performed for evaluation of the
&, theunsigned intis converted to along. The conversion of a 16-bitunsigned inttolongis well-defined because every value representable by a 16-bitunsigned intis also representable by a 32-bitlong.There's no sign extension needed because the initial type is not signed, and the result of using
0xFFFFis the same as the result of using0xFFFFL.Alternatively, if
intis wider than 16 bits, then0xFFFFis of typeint. It is a signed, but positive, number. In this case both operands are signed, andlonghas the greater conversion rank, so theintis again promoted tolongby the usual arithmetic conversions.As others have said, you should avoid performing bitwise operations on signed operands because the numeric result is dependent upon how signedness is represented.
Aside from that, there's nothing particularly wrong with this code. I would argue that it's a style concern that
valueis not initialized when it is declared, but that's probably a nit-pick level comment and depends upon the contents of the//some stuffsection that was omitted.It's probably also preferable to use a fixed-width integer type (like
uint32_t) instead oflongfor greater portability, but really that too depends on the code you are writing and what your basic assumptions are.我认为根据 long 的大小，0xffff 文字 (-1) 可以提升到更大的大小，并且作为有符号值，它将被符号扩展，可能会变成 0xffffffff（仍然是 -1）。
I think depending on the size of a long the 0xffff literal (-1) could be promoted to a larger size and being a signed value it will be sign extended, potentially becoming 0xffffffff (still -1).
我假设这是因为 long 没有预定义大小，除了它必须至少与前面的大小 (int) 一样大。因此，根据大小，您可以将值截断为位的子集（如果 long 大于 32 位）或溢出（如果它小于 32 位）。 是的，多头（根据规范，感谢评论中的提醒）必须能够至少容纳 -2147483647 到 2147483647 （LONG_MIN 和 LONG_MAX）。
I'll assume it's because there's no predefined size for a long, other than it must be at least as big as the preceding size (int). Thus, depending on the size, you might either truncate value to a subset of bits (if long is more than 32 bits) or overflow (if it's less than 32 bits).Yeah, longs (per the spec, and thanks for the reminder in the comments) must be able to hold at least -2147483647 to 2147483647 (LONG_MIN and LONG_MAX).
因为一个值在执行之前没有初始化，所以我认为行为是未定义的，值可以是任何东西。
For one value isn't initialized before doing the and so I think the behaviour is undefined, value could be anything.
long 类型大小是特定于平台/编译器的。
你在这里可以说的是：
long type size is platform/compiler specific.
What you can here say is:
虽然有人可能会说，由于这不是缓冲区溢出或其他可能被利用的错误，所以这是一种风格的事情，而不是错误，但我 99％ 确信问题的答案-writer 正在寻找的是
value在分配之前进行操作。该值将是任意垃圾，这不太可能是本意，因此它“可能是错误的”。While one could argue that since it's not a buffer-overflow or some other error that's likely to be exploitable, it's a style thing and not a bug, I'm 99% confident that the answer that the question-writer is looking for is that
valueis operated on before it's assigned to. The value is going to be arbitrary garbage, and that's unlikely to be what was meant, so it's "potentially wrong".使用 MSVC，我认为该语句将执行最有可能的意图 - 即：清除除最低有效 16 位值之外的所有值，但我遇到过其他平台，它们会将文字 0xffff 解释为相当于（短）-1，然后使用符号扩展转换为长整型，在这种情况下，语句“value &= 0xFFFF”将不起作用。
“value &= 0x0FFFF”更加明确和稳健。
Using MSVC I think that the statement would perform what was most likely intended - that is: clear all but the least significant 16 bits of value, but I have encountered other platforms which would interpret the literal 0xffff as equivalent to (short)-1, then sign extend to convert to long, in which case the statement "value &= 0xFFFF" would have no effect.
"value &= 0x0FFFF" is more explicit and robust.