问题标签 [cstdint]

为什么 C++ 没有 <cstdfloat> 标头用于浮点数，就像它有 <cstdint> 用于整数一样？

编辑 ：

<cstdfloat> 我的意思是为 float 和 double 提供 typedef 的标头。很像 Qt 中的 qreal typedef。希望我的问题现在很清楚。

Boost 的 C99 stdint 实现非常方便。不过，有一件事困扰着我。他们将所有的 typedef 转储到boost namespace. 这让我在使用这个工具时有三个选择：

1. 使用“ using namespace boost”
2. 使用“ using boost::[u]<type><width>_t”
3. 显式引用带有boost::前缀的目标类型；例如，boost::uint32_t foo = 0;

• 选项№ 1 破坏了命名空间的意义。即使在本地范围内使用（例如，在函数内），函数参数之类的东西仍然必须像选项№ 3 一样添加前缀。
• 选项№ 2 更好，但是这些类型有很多，所以它会变得嘈杂。
• 选项№ 3 增加了极高的噪音水平；boost::前缀通常≥相关类型的长度。

我的问题是：将所有这些类型带入全局命名空间的最优雅的方式是什么？我应该只写一个boost/cstdint.hpp使用选项№2的包装器并完成它吗？

此外，像这样包装标头在 VC++ 10 上不起作用（标准库标头的问题）：

编辑：我想另一种选择是使用预处理器使其在 VC 10 上工作？取上面的片段：

工作量少，我猜？

背景：

我有模板流运算符（例如operator << (ostream &, std::vector <T>)）（输出可能是某种 8 位整数类型的容器元素（例如unsigned char，，int_least8_t等等）。

问题：

默认是这些类型输出为char(ASCII)。我只使用char（或wchar_t其他）ASCII 变量，从不使用无符号/有符号类型。即使调用者不知道类型，如何让这些其他 8 位类型始终输出为signed int/ （数字）？unsigned int

第一次尝试：

例如，我尝试过（使用 GCC）在其中使用强制转换进行定义operator << (ostream &, unsigned char)（即stream << static_cast <int> (value). 这适用于unsigned char值，但随后uint8_t仍将输出作为char.

相同的底层类型（即unsigned/signed char不能在重载中使用，所以我不能定义例如operator << (ostream &, int_fast8_t).

我在使用 C++ 类型特征时遇到了一些奇怪的行为，并将我的问题缩小到这个古怪的小问题，我将给出大量解释，因为我不想留下任何误解。

假设你有一个这样的程序：

在使用 GCC（以及 32 位和 64 位 MSVC）的 32 位编译中，程序的输出将是：

但是，由 64 位 GCC 编译产生的程序将输出：

这很奇怪，因为long long int它是一个有符号的 64 位整数，并且就所有意图和目的而言，与long intandint64_t类型相同，因此在逻辑上，int64_t,long int和long long int将是等效类型 - 使用这些类型时生成的程序集是相同的。一看就stdint.h知道为什么：

在 64 位编译中，int64_tis long int，而不是 a long long int（显然）。

这种情况的修复非常简单：

但这是非常骇人听闻的，并且不能很好地扩展（物质的实际功能uint64_t，等）。 所以我的问题是：有没有办法告诉编译器 along long int也是 a int64_t，就像long intis 一样？

我最初的想法是，由于 C/C++ 类型定义的工作方式，这是不可能的。没有办法为编译器指定基本数据类型的类型等效性，因为这是编译器的工作（并且允许这样做可能会破坏很多事情）并且typedef只有一种方式。

我也不太关心在这里得到答案，因为这是一个超级骗局的边缘案例，我不怀疑当示例不是非常人为设计时有人会关心（这是否意味着这应该是社区维基？） .

附加：我使用部分模板专业化而不是更简单的示例的原因，例如：

是说示例仍然可以编译，因为long long int它可以隐式转换为int64_t.

附加：到目前为止，唯一的答案假设我想知道类型是否为 64 位。我不想误导人们认为我关心这一点，并且可能应该提供更多关于这个问题在哪里表现出来的例子。

在此示例中，some_type_trait<long int>将是 a boost::true_type，但some_type_trait<long long int>不会是。虽然这在 C++ 的类型概念中是有道理的，但它是不可取的。

另一个例子是使用一个限定符same_type（这在 C++0x 概念中很常见）：

该示例无法编译，因为 C++（正确）认为类型不同。g++ 将无法编译，并出现如下错误：没有匹配的函数调用same_type(long int&, long long int&)。

我想强调一下，我理解为什么会发生这种情况，但我正在寻找一种不会强迫我到处重复代码的解决方法。

我一直在思考是否应该使用里面的typedef <cstdint>。

uint32_t我个人更喜欢一遍又一unsigned int遍地int8_t写作……char因为它对我来说更直观。

你们有什么感想？<cstdint>使用来自或不使用 typedef 是一个好主意 吗？有什么缺点吗？

我刚刚开始编写自己的内存管理器，但要做到这一点，我需要某种类型的包含文件来创建一个f32（浮点整数）。

我已经#include <cstdint>在我的程序中，但我不确定我需要什么 a F32，或者I32就此而言。

今天我正在尝试在cstdint头文件中定义的一些类型： std::uint16_t等等std::uint_least16_t..

我认为它们非常有用，因为您确切地知道或至少知道它们有多大，这与更常见的特定于平台的问题不同：int、unsigned int等。但是我认为有一个问题会导致许多错误。

假设我们有以下代码：

我们知道std::uint_fast16_t应该至少有 2 个字节。

如果uint_fast16_t恰好是 2 个字节，则此代码会因溢出而发出警告。但在我的情况下，它uint_fast16_t是 8 个字节（之前检查过）。

所以在我的例子中，这段代码编译并运行良好，在另一个例子中我们得到一个警告。我们的代码不可移植。这对我来说是错误的。即使变量可以保存该数据，编译器至少应该给我们一个警告或建议我们使用更大的类型。我对吗？还是我误解了这些类型的目的？

我使用带有这些标志的 g++ 编译了代码

-Wall -Werror -pedantic -std=c++0x

我正在尝试编译 2007 年编写的 C++ 软件包，但出现此错误：

error: ‘uint32_t’ does not name a type

这发生在使用 g++ 4.5.2 的 64 位 Ubuntu 中。它使用 g++ 4.1.2 在 64 位 CentOS 上编译良好。

#include我缺少一个或一个编译器标志吗？或者，我应该使用typedef分配uint32_t给 asize_t还是 a unsigned int？

stdint.h和 和有什么不一样cstdint？

它们都在 MSVC (Visual Studio 2010) 和 gcc-4.5.1 中可用。还都定义了intX_t/uintX_t类型（其中类型X的大小以字节为单位）。

• 如果两个标题中的基本原理相同（便携式类型），我必须做出哪些决定来决定其中一个？

stdint.h定义了没有任何命名空间的每个类型，类型cstdint位于std命名空间中。

• 是否有任何理由将定义的类型包含或不包含到std命名空间中？这两个标题有什么不同？

cstdint没有文件扩展名并使用c前缀，stdint.h使用.h扩展名。

• 此标头的命名约定是什么？c前缀表明这是一个 C 库？中缺少文件扩展名是有原因的cstdint吗？

我正在尝试在命令上构建几个项目，例如，但我一直因为找不到<cstdint>. 该项目尝试在到达包含路径中的特定行时构建一个，特别#include <cstdint>是它会引发错误

这令人费解，因为该文件位于我的主路径中，但它看起来像但找不到。我真的不太了解编译器和路径，所以请原谅我的无知。

关于我的计算机和我正在尝试运行的内容的一些背景知识。这是一台 MacBook Pro，我正在运行 Xcode 4.6.2。我正在构建的框架是 Cinder 框架，而引发错误的文件是Cinder.h. 任何帮助将不胜感激。谢谢！