可移植代码-每个字符的位数

Portable code - bits per char

本文关键字：字符 代码 可移植      更新时间：2023-10-16

我知道C/C++标准只保证每个字符的最小为8位，理论上9/16/42/其他任何事情都是可能的，因此所有关于编写可移植代码的网站都警告不要假设8bpc。我的问题是，这到底有多"不可移植"？

让我解释一下。在我看来，有三类系统：

  1. 计算机-我指的是运行Mac/Linux/Windows/Unix/*nix/posix/任何东西的台式机、笔记本电脑、服务器等（我知道这个列表并不完全正确，但你明白了）。如果听说char不是恰好8位的任何这样的系统，我会非常惊讶。（如果我错了，请纠正我）
  2. 带有操作系统的设备-这包括智能手机和此类嵌入式系统。虽然我不会很惊讶地发现这样一个char超过8位的系统，但到目前为止我还没有听说过（再次，如果我只是不知道，请通知我）
  3. 裸金属设备-录像机、微波炉、旧手机等。在这个领域，我没有任何经验，所以任何事情都可能在这里发生。然而，我真的需要我的代码在Windows桌面和微波炉之间跨平台吗？我是否可能拥有两者通用的代码

一句话：是否存在char是而不是8位的常见（超过%0.001）平台（在上述类别1和2中）？我的上述猜测是真的吗？

使用限制.h

CHAR_BIT

http://www.cplusplus.com/reference/clibrary/climits/

此外，当您想要使用给定的大小时，请使用stdint.h

例如，许多DSP的CHAR_BIT大于或等于16。

至少，与64位架构中的整数大小类似，未来的平台可能会使用更宽的字符，使用更多的位。ASCII字符可能会过时，取而代之的是unicode。这可能是一个谨慎的原因。

您通常可以安全地假设文件将具有8位字节，如果没有，则可以通过常用工具将8位字节的文件转换为零填充的本地格式。但是，假设CHAR_BIT==8要危险得多。目前几乎总是这样，但未来可能不会总是这样。8位内存访问越来越成为一个瓶颈。

Posix标准要求CHAR_BIT为8。

因此，如果您只关心您的代码在符合Posix的平台上运行，那么假设CHAR_BIT==8是很好的。

绝大多数商品PC平台和构建系统都符合这一要求。大多数使用BSD套接字接口的平台都可能隐含地具有这一要求，因为平台字节是八位字节的假设分布非常广泛。

#if CHAR_BIT != 8
#error Your platform is unsupported!
#endif

POSIX为什么强制CHAR_BIT==8？

如果您希望您的代码今天在嵌入式和深奥的平台上运行，那么您只应该担心这种假设/约束。否则，在我看来，这是一个相当安全的假设。

相关文章：