0

在 C99 和 C11（至少是它们的最终草案）中，我们发现需要存在uint_least8_t, uint_least16_t, uint_least32_t, uint_least64_tin<stdint.h>以及它们的签名变体。

我认为要求1 到 64 之间uint_least{N}_t的所有N的可用性是合理的。有充分的理由说明情况并非如此吗？如果实现必须提供 8、16、32 和 64，那么对于所有较小的N值的实现肯定应该是可行的（例如typedef uint_least16_t uint_least15_t;，对于 x86，等是显而易见的）。

我之所以问，是因为我发现自己想要一种uint_least21_t类型来存储单个 Unicode 代码点，它可以具有介于两者之间的任何值U+0000（U+10FFFFUnicode 4.0 中引入的约束）。我认为这将是一个更准确的选择，以防某些目标架构恰好具有（例如）快速 24 位整数。现在，我遇到了一个很大的预处理器部分，我正在测试21 到 32 之间defined(UINT_LEAST{N}_MAX)的N以选择正确的类型。

4

1 回答 1

1

自 1999 年以来的大多数现代硬件（和编译器）都可以合理地实现 8、16、32 和 64 位无符号类型。事实上，在少数现代实现中，unsigned char、unsigned short、unsigned long和unsigned long longARE 实现为 8、16、32 和 64 位无符号类型——尽管严格来说，这是允许的，但不是必需的。

这意味着，对于编译器供应商来说uint_least8_t，uint_least16_t可以轻松支持, , uint_least32_t, 。uint_least64_t编译器供应商不会提出强烈的抵制。

对于其他此类类型，情况并非如此。例如，很少有硬件实例本身支持 N 形式的无符号整数类型，用于uint_leastN_t的其他值。这意味着编译器（或库）将需要模拟这些类型（可能就本机类型而言硬件确实支持）。

此外，在实践中，相对较少的程序员对（比如说） a 有迫切的需求uint_least21_t，甚至更少的程序员愿意付出冷硬的现金来购买一个编译器和库。

所以有多种情况的组合。编译器或库供应商（在委员会程序中拥有投票权）将不太热衷于模拟此类类型，除非从中获利（即许多付费客户愿意为具有此类功能的编译器或库支付高价）。此外，很少有程序员有兴趣使用这种具有足够商业或政治影响力的特性来说服供应商开发支持这种类型的编译器和库的成本（工时等）是值得的。

对于标准化委员会来说，阻力最小的路径是只强制要求其中的几个类型。毕竟，有更多重要的特性可以投票加入标准，而不是一些程序员需要的设施，甚至更少的程序员愿意付费，而且相对较少的供应商会费心去实现。

于 2015-11-02T11:03:17.360 回答