blocks|key|2058044|text|在大多数平台(例如，具有16位或32位int的系统)上，1+<<+31是未定义的行为，因为它的结果不能用int+(表达式的结果类型)表示。不要在代码中使用该表达式。另一方面，在使用32位int的系统上，1U+<<+31是一个有效的表达式，因为它的结果可以用unsigned+int+(表达式的结果类型)表示。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2058045|在32位int系统上，0x80000000是unsigned+int类型的(相对)大的正整数。如果你足够幸运(或不幸)没有使用1+<<+31表达式从你的鼻子里飞出来，那么这个表达式最有可能的结果是INT_MIN，它是一个(相对)+int类型的大的负整数。|2058046|entityMap^0|J|3|S|7|1G|3|2L|3|2T|8|3K|C|0|4|3|B|A|M|C|1R|7|2Q|7|37|3|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|I|$]]

<code>1 &lt;&lt; 31</code> is undefined behavior on most platforms (e. g., systems with 16-bit or 32-bit <code>int</code>) as its result cannot be represented in an <code>int</code> (the resulting type of the expression). Don't use that expression in code. On the other hand <code>1U &lt;&lt; 31</code> is a valid expression on systems with 32-bit <code>int</code> as its result is representable in an <code>unsigned int</code> (the resulting type of the expression).

On a 32-bit <code>int</code> system, <code>0x80000000</code> is a (relatively) big positive integer number of type <code>unsigned int</code>. If you are lucky (or unlucky) enough to not have demons to fly out of your nose by using <code>1 &lt;&lt; 31</code> expression, the most likely result of this expression is <code>INT_MIN</code> which is a (relatively) big negative integer number of type <code>int</code>.

blocks|key|2515941|text|0x80000000是一个大数字，需要32位来表示该数字。这意味着在32位系统上(或在32位兼容应用程序中)，int太小。所以改用unsigned+long：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2515942|#define+SCALE+(1u+<<+31)

#define+fix_Q31_80(x)+(+(unsigned+long)+(+(float)(x)*(float)0x80000000u+)+)
#define+fix_Q31_SC(x)+(+(unsigned+long)+(+(float)(x)*(float)SCALE+++++++)+)

int+main()
{
++++unsigned+long+fix_80+=+fix_Q31_80(0.5f);
++++unsigned+long+fix_sc+=+fix_Q31_SC(0.5f);
}|code-block|syntax|javascript|2515943|entityMap^0|1J|3|1T|D|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|L|$]]

0x80000000 is a big number which needs 32 bit to represent that number. This means on a 32 bit system (or in a 32 bit compatible application) an <code>int</code> is too small. So use <code>unsigned long</code> instead:

<pre><code>#define SCALE (1u &lt;&lt; 31)

#define fix_Q31_80(x) ( (unsigned long) ( (float)(x)*(float)0x80000000u ) )
#define fix_Q31_SC(x) ( (unsigned long) ( (float)(x)*(float)SCALE ) )

int main()
{
 unsigned long fix_80 = fix_Q31_80(0.5f);
 unsigned long fix_sc = fix_Q31_SC(0.5f);
}
</code></pre>

blocks|key|2403210|text|所有整数常量都有一个类型。在1的情况下，类型是int。在包含32位整数的系统上，1+<<+31给出的数字太大，无法表示为int。这是未定义的行为，因此是一个错误。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2403211|但0x80000000将按预期工作，因为在32位系统上，它恰好是unsigned+int类型。这是因为当编译器查找十进制常量和十六进制常量应该具有的类型as+explained+here时，它们的行为是不同的。|2403212|正如一些人所提到的，不要在有符号类型上使用位运算符。|2403213|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/34183176/584518^0|E|1|N|3|14|7|1O|3|0|1|A|W|C|24|H|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|10|8|@$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@$9|15|A|16|1|17]]|E|$]]|$1|H|3|I|5|6|7|18|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

All integer constants have a type. In the case of <code>1</code>, the type is <code>int</code>. On a system with 32 bit integers, <code>1 &lt;&lt; 31</code> gives a number which is too large to be represented as an <code>int</code>. This is undefined behavior and therefore a bug. 

But <code>0x80000000</code> will work as expected, because on a 32 bit system it happens to be the type <code>unsigned int</code>. This is because decimal constants and hexadecimal constants behave differently when the compiler goes looking for what type they should have, <a href="https://stackoverflow.com/a/34183176/584518">as explained here</a>. 

As several people have mentioned, don't use bitwise operators on signed types.

<pre><code>#define SCALE (1 &lt;&lt; 31)

#define fix_Q31_80(x) ( (int) ( (float)(x)*(float)0x80000000 ) )
#define fix_Q31_SC(x) ( (int) ( (float)(x)*(float)SCALE ) )

int main()
{
 int fix_80 = fix_Q31_80(0.5f);
 int fix_sc = fix_Q31_SC(0.5f);
}
</code></pre>

Why are the values <code>fix_80</code> and <code>fix_sc</code> different? 

<pre><code>fix_80 == Hex:0x40000000
fix_sc == Hex:0xc0000000
</code></pre>

Defining (1 << 31) or using 0x80000000? Result is different

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

#define SCALE (1 << 31)#define fix_Q31_80(x) ( (int) ( (float)(x)*(float)0x80000000 ) )#define fix_Q31_SC(x) ( (int) ( (float)(x)*(float)SCALE ) )int main(...

问定义(1 << 31)还是使用0x80000000？结果不同
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问定义(1 << 31)还是使用0x80000000？结果不同EN