问题标签 [cstdint]

当我将 Apportable 用于我的 C++ 源代码时，它找不到在stdint.h.

该代码在 Xcode 上运行良好，并且此错误仅在 Apportable 上引发。我加了#include <cstdint>，但没有效果。

这是我当前的.cpp文件。

我错过了什么？

我正在实现 C 代码以将 16 位符号和幅度整数复制到 8 位符号和幅度整数。这甚至可能吗？有人可以解释一下如何做到这一点吗？

代码片段：

如何将前两位数字复制到变量b，然后将后两位数字复制到变量c？

我只是偶然发现了这种类型u_int8_t，因为它没有在 Windows+MinGW 中编译（但在 Linux 下编译得很好）。根据这个站点，C++11 标准定义了 type uint8_t。我只使用了后者，一切正常。

出现的问题是：

1. u_int8_t和有什么区别uint8_t吗？
2. 是否有理由（除了遗留代码）使用u_int8_t？
3. 如果我使用 C++11 编译器（在不同的操作系统或架构上） ，假设它uint8_t会出现是否安全？
4. 上述问题的答案是否也适用于其他类型（intX_t和uintX_t）？

我正在尝试在代码块中编译树莓派 B+ 上的 C++ 项目。代码取自这里

带有 [std=c++0x] 标志的 GCC 4.6 给了我下一个错误：

正如你所看到的，我有<cstdint>和using namespace std线。我究竟做错了什么？

是否有可能，至少在理论上，cstdint typedefs 绑定到某些特定于实现的类型 std::numeric_limits 不是专门针对的？

根据http://www.cplusplus.com/reference/limits/numeric_limits，让我引用一下，“ [std::numeric_limits] 专门用于每种基本算术类型，其成员描述类型 T 的属性。此模板不应专门用于任何其他类型。 ”

根据http://en.cppreference.com/w/cpp/types/numeric_limits，让我再次引用，“实现可以为特定于实现的类型提供 std::numeric_limits 的特化”。

“五月”，cppreference 说。所以他们不必这样做。

最后，根据http://www.cplusplus.com/reference/cstdint，标题中定义的 typedef 是“基本整数类型或扩展整数类型的 typedef ”。

因此，总而言之 - 似乎 cstdint typedefs 可能绑定到扩展整数类型（无论它们是什么），它们不是基本的整数类型（同样，无论它们是什么），因此可能与 std::numeric_limits 不兼容。这个对吗？

但是，我链接到的文档在某一点上似乎略有不一致。cplusplus.com 是否禁止 std::numeric_limits 不得专门用于任何非基本算术类型，以反对 cppreference 允许 std::numeric_limits 可能专门用于特定于实现的类型？当然，除非这些特定于实现的类型实际上是 基本的整数类型，在这种情况下，希望 std::numeric_limits 必须专门用于所有 cstdint typedef。

这些文件让我感到困惑。所以我在这里问我的问题:)

编辑。

根据http://eel.is/c++draft/cstdint， cstdint 必须绑定到整数类型。并且根据http://eel.is/c++draft/limits.numeric，“应为每种算术类型提供专门化，包括浮点数和整数，包括 bool ”。整数类型是算术类型，因此 std::numeric_limits 必须专门用于 cstdint typedefs 的理解是否正确？

在 C 语言中，使用相同的源代码来定位不同的处理器架构是很常见的（或者至少是可能的）。处理器架构以不同方式定义整数大小也很常见。为了增加代码可移植性并避免整数大小限制，建议使用 C 标准整数标头。但是，我对这实际上是如何实现的感到困惑。

如果我正在编写一个为 x86 编写的小 C 程序，然后决定将其移植到 8 位微控制器上，那么微控制器编译器如何知道如何将 'uint32_t' 转换为其本机整数类型？

编写 C 编译器时是否有一些映射要求？例如，如果您的编译器要与 C99 兼容，您是否需要一个映射功能，将所有 uint32_t 替换为本机类型？

谢谢！

在尝试在 Windows 10 中编译 DOSBox SVN Daum 时，我遇到了与 VS2015 明显相关的标头相关问题。示例：

我的搜索告诉我这种问题已经发生在周围的项目中，但我无法修复它。

特别是，我阅读了 VisualStudio 2015 RC Issue with Includes和https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/，然后更改了 AppData\Local 的内容\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props 到：

虽然没有运气。:(

图片：

我远不是一个有经验的 C 程序员。谁能告诉我缺少什么？谢谢！

典型的外汇价格将执行到小数点后第四位；例如，今天英镑兑美元的当前价格是1.2515。我已经看到这个价格执行到更多的小数位。

这真的是一个两部分的问题。

第一的

我正在考虑两种方案：

a)浮点类型；double跳到脑海。我有点担心这里的舍入误差。
b)整数类型，分别存储小数和整数部分。

还有其他现实的选择吗？

在那些（上面）中，哪一个是正确的？

第二

<cstdint>在任一方案中，我都会精确指定通过库使用的位数。

多少位才有意义？

我希望平衡准确性、内存/存储成本和（当然）性能。

谢谢，基思 :^)

我们都知道，在 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 位的原始类型的基本原理是什么？而且，由于这肯定会对实践中的实施者产生严重影响，他们对此有何反应/处理？

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

我正在开发一个涉及路线查找（一个完全不同的主题）的应用程序，但是为了测试，我需要示例迷宫进行测试。一位同事建议我使用pydaedalus以我需要的格式生成大型迷宫。我正在使用以下代码尝试安装模块：

这将返回以下错误：

我做了一些研究，但没有发现任何可以解决这个问题的东西。我还使用 cstdint 进行了一些（有限的）C++ 开发，这一直有效。

我遇到了这个问题，但它似乎解决了一个单独的问题。
我正在 OSX 10.10.5 中开发

非常感谢您提供的任何帮助！