“长期”禁令有意义吗？

 Data model  | short |   int |   long | long long | pointers/size_t  | Sample operating systems
... 
LLP64/IL32P64   16      32      32     64           64                Microsoft Windows (x86-64 and IA-64)
LP64/I32LP64    16      32      64     64           64                Most Unix and Unix-like systems, e.g. Solaris, Linux, BSD, and OS X; z/OS
...
 

#1 楼

我今天使用long的唯一原因是在调用或实现一个使用它的外部接口时。

正如您在帖子中所说，short和int在当今所有主要台式机/服务器/移动平台上都具有相当稳定的特征，我认为在可预见的将来没有任何改变的理由。因此，我几乎没有理由避免使用它们。另一方面，long很乱。我知道在所有32位系统上，它都具有以下特征。


它的大小恰好是32位。
它与内存地址的大小相同。
它与最大数据单元的大小相同。可以保存在普通寄存器中并使用一条指令进行处理。

基于这些特征中的一个或多个，编写了大量代码。但是，随着迁移到64位，不可能保留所有这些。类似于Unix的平台使用了以特征1为代价保留特征2和3的LP64。Win64用了以特征2和3为代价保留特征1的LLP64。结果是您不能再依赖那些特征中的任何一个了。而且IMO几乎没有理由使用long。

如果要使用大小恰好为32位的类型，则应使用int32_t。

如果要使用与指针大小相同，应该使用intptr_t（或更好的uintptr_t）。

如果您想要的类型是可以在单个寄存器/指令中处理的最大项，那么我不知道认为该标准提供了一个标准。 size_t在大多数常见平台上都应该正确，但在x32上则不正确。


P.S.

我不会理会“快速”或“最小”类型。 “最小”类型仅在您关心可移植性以使CHAR_BIT != 8真正模糊的体系结构时才重要。实际上，“快速”类型的大小似乎很随意。 Linux似乎使它们的大小至少与指针相同，这在具有快速32位支持的64位平台（如x86-64和arm64）上是愚蠢的。 IIRC iOS使它们尽可能小。我不确定其他系统还能做什么。


P.P.S

使用unsigned long（而不是简单的long）的一个原因是，它被保证具有模数特性。不幸的是，由于C搞砸了促销规则，小于int的无符号类型没有模数行为。

在当今的所有主要平台上，uint32_t的大小相同或大于int，因此具有模数行为。但是，从历史上看，从理论上讲，将来的平台中int是64位的，因此uint32_t不具有模数行为。

我个人认为最好进入强迫行为的习惯。在方程式的开头使用“ 1u *”或“ 0u +”进行模运算，因为它适用于任何大小的无符号类型。

#2 楼

正如您在问题中提到的那样，现代软件就是有关Internet上的平台和系统之间进行互操作的。 C和C ++标准提供了整数类型大小的范围，而不是特定大小的范围（与Java和C＃之类的语言相反）。

要确保在不同平台上编译的软件可以使用相同的数据，并且并确保其他软件可以使用相同大小与您的软件进行交互的方式，您应该使用固定大小的整数。

输入<cstdint>，它提供了确切的信息，并且是所有编译器和标准程序的标准标头需要提供图书馆平台。注意：从C ++ 11开始，才需要此标头，但是无论如何，许多较早的库实现都提供了它。

想要64位无符号整数吗？使用uint64_t。带符号的32位整数？使用int32_t。虽然标头中的类型是可选的，但现代平台应支持该标头中定义的所有类型。

有时需要特定的位宽，例如，用于与其他设备通信的数据结构中系统。有时不是。对于不太严格的情况，<cstdint>提供的宽度最小。

变量最少：int_leastXX_t是最小XX位的整数类型。它将使用提供XX位的最小类型，但是允许该类型大于指定的位数。实际上，这些类型通常与上述提供确切位数的类型相同。

还有一些快速变体：int_fastXX_t至少为XX位，但应使用在特定平台上可快速执行的类型。在此上下文中，“快速”的定义是不确定的。但是，实际上，这通常意味着小于CPU寄存器大小的类型可能会别名为CPU寄存器大小的类型。例如，Visual C ++ 2015的标头指定int_fast16_t是32位整数，因为在x86上32位算术总体上比16位算术快。

这很重要，因为您应该能够使用不管平台如何，都可以保存程序执行的计算结果。如果程序在一个平台上产生正确的结果，但由于整数溢出的差异而在另一个平台上产生不正确的结果，那就不好了。通过使用标准整数类型，可以保证在不同平台上使用的整数大小方面的结果相同（当然，除了整数宽度以外，平台之间可能还会存在其他差异）。

因此，是的，应该禁止现代C ++代码使用long。 int，short和long long也应该如此。

#3 楼

不，禁止内置整数类型将是荒谬的。但是，它们也不应被滥用。

如果您需要一个正好为N位宽的整数，请使用std::intN_t（如果需要std::uintN_t版本，请使用unsigned）。将int视为32位整数并将long long视为64位整数是错误的。在当前平台上，可能碰巧是这种情况，但这依赖于实现定义的行为。

使用固定宽度整数类型对于与其他技术进行互操作也很有用。例如，如果应用程序的某些部分是用Java编写的，而其他部分是用C ++编写的，则可能需要匹配整数类型，以便获得一致的结果。 （仍然要注意，Java中的溢出具有明确定义的语义，而C ++中的signed溢出是未定义的行为，因此一致性是一个很高的目标。）在不同计算主机之间交换数据时，它们也将具有无价的价值。

如果您不需要N位，而只是一个足够宽的类型，请考虑使用std::int_leastN_t（针对空间进行了优化）或std::int_fastN_t（针对速度进行了优化）。同样，两个系列也都有对应的unsigned。

那么，什么时候使用内置类型？好吧，由于该标准并未精确指定其宽度，因此，当您不在乎实际位宽而在乎其他特征时，请使用它们。

char是可由硬件寻址的最小整数。该语言实际上强迫您使用它来别名任意内存。它也是表示（窄）字符串的唯一可行类型。

int通常是机器可以处理的最快类型。它足够宽，可以用一条指令加载和存储（而不必屏蔽或移位位），也可以足够窄，以便可以用（最有效的）硬件指令进行操作。因此，int是无需担心溢出时传递数据和进行算术运算的理想选择。例如，枚举的默认基础类型为int。不要仅仅因为可以就将其更改为32位整数。另外，如果您的值只能为–1、0和1，则int是一个完美的选择，除非您要存储它们的巨大数组，在这种情况下，您可能希望使用更紧凑的数据类型为访问单个元素而必须支付的更高价格的成本。更有效的缓存可能会为您带来回报。还根据int定义了许多操作系统功能。来回转换他们的论点和结果将是愚蠢的。所有可能要做的就是引入溢出错误。

long通常是可以用单机器指令处理的最宽的类型。这尤其使unsigned long在处理原始数据和各种位处理方面非常有吸引力。例如，我期望在位向量的实现中看到unsigned long。如果代码写得很仔细，则类型的实际宽度没有多大关系（因为代码会自动适应）。在本机字为32位的平台上，使位向量的支持数组为unsigned的数组是最理想的32位整数，因为使用必须通过昂贵的方式加载的64位类型会很愚蠢指令只能再次移位和掩盖不需要的位。另一方面，如果平台的本机字长为64位，则我希望使用该类型的数组，因为这意味着“查找第一组”之类的操作可能会快两倍。因此，您所描述的long数据类型的“问题”因平台而异，实际上是可以充分利用的功能。仅当您将内置类型视为具有一定宽度的类型时，这才成为问题，而它们根本不是。

char，int和long是如上所述非常有用的类型。 short和long long的用处不大，因为它们的语义不太清楚。

#4 楼

另一个答案已经详细说明了cstdint类型及其中鲜为人知的变体。
我想补充一点：
使用特定于域的类型名称
，即，不要声明您的参数和变量为uint32_t（不一定是long！），但是诸如channel_id_type，room_count_type等名称。
关于库
使用long的第三方库可能会很烦人，尤其是用作参考或指向这些指针的指针。
最好的方法是制作包装器。
通常，我的策略是制作一组将使用的类型转换函数。它们被重载为仅接受与相应类型完全匹配的那些类型，以及您需要的任何指针等变体。它们是针对os / compiler / settings定义的。这使您可以删除警告，并确保仅使用“正确的”转换。

channel_id_type cid_out;
...
SomeLibFoo (same_thing_really<int*>(&cid_out));

特别是，由于产生32位的不同原始类型，您对int32_t的定义方式选择可能与库不匹配调用（例如，在Windows上为int vs long）。
类似cast的函数记录冲突，在与函数参数匹配的结果上进行编译时检查，并在且仅当实际类型时删除任何警告或错误匹配所涉及的实际大小。也就是说，如果我（在Windows上）传递了int*或long*并给出了编译时错误，则会超载并定义它。
因此，如果库已更新或有人更改了channel_id_type，则继续被验证。