问题标签 [integer-promotion]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - 何时将类型提升为无符号整数？
这篇文章说：
如果原始类型的所有值都可以表示为 int，则将较小类型的值转换为 int；否则，将其转换为无符号整数
signed/unsigned char和的所有值signed/unsigned short都可以表示为int，那么什么时候将类型提升为unsigned int？
java - 在java中为什么前缀增量或减量运算符不需要在字节的情况下进行转换
在java中假设我有以下代码片段
c - 使用 unsigned int 而不是 unsigned short 会改变行为
我正在尝试htoi(char*)K&R 的 The C Programming Language 中的函数（练习 2-3，第 43 页）。
该函数旨在将十六进制字符串转换为基数 10。
我相信我有它的工作。这是我的代码：
我的问题是htoi(char*)函数中的以下行：
当我删除shortmakefirstIndex变成一个unsigned int而不是一个unsigned short int，我得到一个无限循环。
因此，当我从 in 后面开始时s，htoi(char* s)永远i >= firstIndex不会评估为假。
为什么会这样？我是否遗漏了一些微不足道的事情，或者我做了一些非常错误的事情来导致这种未定义的行为？
objective-c - 当参数大小不同时，Objective-C 如何处理位掩码？
在 Objective-C 中编码时，编译器在对两个不同大小的变量进行按位与（或执行其他按位运算）时应该怎么做？
例如，假设我有一些变量如下：
如果我用一个短尺寸的掩码对长进行位掩码，显然我们只会选择感兴趣的位：
如果我用长位掩码短，
看起来这应该用零填充顶部，
但它是否保证会这样做，或者它可能是任何碰巧在内存中的东西，更像是：
显然，后者可能会产生未指定的效果，并且是不可取的。
我在正在清理的程序中发现了这种性质的代码，我只是增加了类型的大小以确保安全，但我想知道它是否真的有必要。
c - 为什么在 C 中的加法过程中提升整数类型？
所以我们遇到了一个现场问题，经过几天的调试，将问题缩小到这个特定的代码位，其中没有发生 while 循环中的处理：
这运行良好，直到我们达到 65535 的 uint16 限制。稍后，另一组打印语句，我们发现它numberA + 1的值为65536，而numberB回绕回0。这未通过检查，并且未进行任何处理。
这让我很好奇，所以我整理了一个快速的 C 程序（用 GCC 4.9.2 编译）来检查：
结果是：
所以看起来结果numberA + 1被提升为uint32_t。这是C语言的意图吗？或者这是一些编译器/硬件的奇怪之处？
c - 一元减号是否等于二元减号？
我的 C 编译器在对unsigned值使用一元减法时发出警告，因此我通过从 0 中减去来修复警告。
现在我想知道当前代码是否等同于原始代码：
我的问题是：对于相同的值，b两行代码是否会产生相同的结果a？
c++ - 为什么将 auto 推导出为 int 而不是 uint16_t
我有以下代码：
我希望第一个断言会失败，而第二个断言不会。然而gcc 4.9.2，clang 3.6反其道而行之。如果我在代码中使用 uint16_t 而不是 auto ，则正确的断言会失败，而另一个断言会成功。
PS 最初我只是1代替static_cast<uint16_t>(1)并认为问题是由于数字文字1的类型为 int 但即使在此处显式转换后错误断言也会失败。
c - 整数提升、值位和乘法
如果我们将两种uint32_t类型相乘，并且它们int在该系统上的类型有 63 个值位和一个符号位，那么这些值将转换为int（整数提升）、相乘并转换回uint32_t. 中间结果不能用int:表示2^32-1 * 2^32-1 > 2^63-1，并触发有符号整数溢出，导致未定义的行为。
的UINT32_MAX值为2^32-1，因为uint32_t保证有 32 个值位。
由于具有 64 位大小的 int 平台很常见，我的结论是否正确？由于类型是无符号的，程序员期望结果会换行，但整数提升会因为有符号溢出而导致未定义的行为。
c - 运算符优先级和自动提升（避免溢出）
以字节为单位查找某些数据的大小是一种常见的操作。
人为的例子：
这里明显的错误是整数会溢出（例如，23171x23171 RGBA 字节缓冲区）。
乘以3 个或更多 值时的提升规则是什么？
（将一对值相乘很简单）
我们可以稳妥行事，直接投：
另一种选择是添加括号以确保乘法和提升的顺序是可预测的（并且对之间的自动提升按预期工作）......
...这行得通，但我的问题是。
是否有确定的方法可以将 3 个或更多值相乘以确保它们会自动提升？
（避免溢出）
或者这是未定义的行为？
笔记...
- 在这里使用
size_t不会防止溢出，它只是防止溢出该类型的最大值。 - 在给出的示例中，参数也可以是有意义的
size_t，但这不是这个问题的重点。
c++ - 如果我想将 char 提升为 int，我应该使用 static_cast（char 变量）或 +（char 变量），为什么？
这个问题有点主观，但我相信它可能会导致一些建设性的答案。假设我有char x;并且我想将它提升为一个整数，以便我可以访问它的数值。我应该更喜欢使用哪个，为什么？static_cast<int>还是一元算术运算符+？
我自己的想法是使用 astatic_cast<int>更加明确和可读。但是，使用一元算术运算符+的代码更短。
一种方法比另一种更安全吗？