问题标签 [stdint]

让我对常规 c 整数声明感到困扰的一件事是它们的名称很奇怪，“long long”是最糟糕的。我只为 32 位和 64 位机器构建，所以我不一定需要库提供的可移植性，但是我喜欢每种类型的名称都是一个长度相似的单词，大小没有歧义。

在 32 位和 64 位机器上：

1) 使用较小的整数（如 int16_t）是否可以比使用更高的整数（如 int32_t）慢？

2) 如果我需要一个 for 循环来运行 10 次，是否可以使用可以处理它的最小整数而不是典型的 32 位整数？

3) 每当我使用一个我知道永远不会为负的整数时，即使我不需要提供的额外范围，是否可以更喜欢使用无符号版本？

4) 对 stdint.h 中包含的类型使用 typedef 是否安全

编辑：两个答案都一样好，我不能真正倾向于一个，所以我只选择了代表较低的回答者

所以我有 4 个 uint16_t，我试图将它们存储在一个 uint64_t 中。我想我有这个工作。

我已经能够编码 4 个 int16_t，然后使用这种方法将它们取回。现在，我想将两个编码形式加在一起，对它们进行解码，然后返回原始操作。我似乎被 1 个错误弄得一团糟。

我这里的输出是 0、-15999、16001、16000。两个输出是正确的（0 和 16000），两个输出差一。

我会注意到我曾尝试先将 int16_t 转换为 uint16_t（添加 32768），但没有成功。

我们都知道，在 C99 中定义的精确宽度整数类型定义stdint.h是可选的，仅当架构具有这些宽度、符号等的原始类型时才定义。

但是，我刚刚意识到这不是[u]int_(fast|least)N_t可选的，而是必需的。参见 ISO/IEC 9899:9999，第 7.18.1 节：

[7.18.1.2] 3需要以下类型：

[7.18.1.3] 3需要以下类型：

因此，如前所述，所有能够提供符合标准的 C 或 C++ 编译器的架构——包括独立的编译器，stdint.h都必须能够提供至少 64 位的原始类型！

鉴于标准在许多其他实现细节上的余地，这对我来说似乎很奇怪。这尤其是因为显然我们自 1999 年以来一直在执行它，在 64 位计算甚至在桌面上成为主流之前几年。更不用说在许多情况下仍然是当前的嵌入式架构之间的滞后。

要求所有实现都具有至少 64 位的原始类型的基本原理是什么？而且，由于这肯定会对实践中的实施者产生严重影响，他们对此有何反应/处理？

（......或者我在阅读中错过了什么，也总是一个答案）

我正在开发一个使用字节数组的小型网络应用程序。传统上，这些将用类似的东西声明char buf[] = ...。

这似乎是在大多数教程中（仍然？）完成的方式，但它的问题是它可能会掩盖实际发生的事情，例如，当您尝试打印这样的数组并忘记并非每个 char 都是可见字符时.

有人建议您应该chars完全停止使用，而改用现代uint8_t. 我觉得这很有吸引力，主要是基于显式优于隐式的原则。

那么，将这些类型的数组声明为 有什么问题uint8_t buf[] = ...吗？

我正在使用 MS Visual Studio 2017 并且（如预期的那样）我收到编译器警告：

在这个 C++ 代码上：

但是，当我使用 cstdint typedefs 时：

...我根本没有收到任何编译器警告。为什么？

此外，作为一种严格类型的语言，C++ 编译器不应该给我错误而不是警告这些方法中的任何一种（并强制我在第三行赋值之前将 32 位值显式转换为 16 位)?

我正在尝试使用我的一个源文件中的 aarch64 交叉编译器从 x86 计算机为树莓派 3 编译一些内核代码，我需要 stdint.h 但是当我尝试编译时它失败了

我正在运行 Fedors 26 并使用过

所以我有所有适当的包或应该有。

I was reading C in a Nutshell and found this:

"If an optional signed type (without the prefix u) is defined, then the corresponding unsigned type (with the initial u) is required, and vice versa."

The paragraph is about The integer types with exact width(C99).

我想为将在不同 MCU（16 位、32 位或 64 位基础）上运行的应用程序编写可移植代码。

• MSP-430
• nRF52（32 位）
• PIC（16 位）
• C51（8 位）

让我们考虑这个片段：

我的问题涉及循环计数器变量的类型，这里是size_t.

通常size_t应该足够大以解决我系统的所有内存。所以使用size_t可能会影响我的代码在某些架构上的性能，因为这个变量的宽度对于我拥有的数组的长度来说太大了。

有了这个假设，我应该更好地使用uint_fast16_t，因为我知道我array的元素少于 65k。

关心这篇文章是否有意义，或者我的编译器是否足够聪明来优化它？

我认为uint_fast16_t与size_t.

更具体地说明我的问题：

我是通过系统地为我的循环计数器（uint_fast8_t, uint_fast16_t, ...）使用正确的类型来提高我的代码的可移植性，还是我应该更喜欢使用size_t，因为在大多数情况下它不会在性能方面产生任何差异？

编辑

根据您的评论和评论，很明显大多数情况下，编译器会注册循环计数器，因此在两者之间进行选择size_t或uint_fast8_t无关紧要。

https://godbolt.org/g/pbPCrf

如果循环长度变得大于内部 CPU 寄存器，例如在 8 位微控制器上执行 512 个循环，这个问题可能会成为一个真正的问题。

我正在编写一个在运行时使用 NVRTC（CUDA 9.2 版和 NVRTC 7.5 版）编译的 CUDA 内核，它需要stdint.h标头，以便拥有int32_t等类型。

如果我编写没有包含的内核源代码，它可以正常工作。例如内核

编译为 PTX 代码，其中 f 定义为.visible .entry f。

但是如果内核源代码是

它报告A function without execution space annotations (__host__/__device__/__global__) is considered a host function, and host functions are not allowed in JIT mode.（也没有extern "C"）。

传递-default-device使 PTX 代码.visible .func f，因此无法从主机调用该函数。

有没有办法在源代码中包含标头，并且仍然具有__global__入口功能？或者，一种方法可以知道 NVRTC 编译器使用哪种整数大小约定，以便int32_t可以手动定义等类型？

编辑： 显示问题的示例程序：

当//#include <stdint.h>内核源代码被取消注释时，它不再编译。取消注释时//options.push_back("-default-device");，它会编译但不会将函数标记f为.entry.

CMakeLists.txt 进行编译（需要 CUDA 驱动 API + NVRTC）

我只是想知道为什么像uintptr_tare in这样的东西stdint.h，但其他类型像size_tare in stddef.h？这些标题背后有逻辑吗？