为什么C编译器指定long为32位而long long为64位?

发布于 2024-12-02 17:37:52 字数 57 浏览 2 评论 0原文

在 128 位数字成为现实之前,制作 long 64 位并保留 long long 不是更有意义吗?

Wouldn't it have made more sense to make long 64-bit and reserve long long until 128-bit numbers become a reality?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

水中月 2024-12-09 17:37:52

是的,这确实有道理,但微软有自己的理由将“长”定义为 32 位。

据我所知,目前所有主流系统中,Windows是唯一“长”为32位的操作系统。在 Unix 和 Linux 上,它是 64 位的。

所有 Windows 编译器都会在 Windows 上将“long”编译为 32 位,以保持与 Microsoft 的兼容性。

因此,我避免使用“int”和“long”。有时我会使用“int”来表示错误代码和布尔值(在 C 中),但我从不将它们用于任何依赖于类型大小的代码。

Yes, it does make sense, but Microsoft had their own reasons for defining "long" as 32-bits.

As far as I know, of all the mainstream systems right now, Windows is the only OS where "long" is 32-bits. On Unix and Linux, it's 64-bit.

All compilers for Windows will compile "long" to 32-bits on Windows to maintain compatibility with Microsoft.

For this reason, I avoid using "int" and "long". Occasionally I'll use "int" for error codes and booleans (in C), but I never use them for any code that is dependent on the size of the type.

心病无药医 2024-12-09 17:37:52

C标准没有规定原始数据类型的位长,而只规定了它们的最小位长。因此编译器可以选择原始数据类型的位长度。在决定每个原始数据类型的位长度时,编译器设计者应该考虑几个因素,包括计算机体系结构。

这是一些参考:
http://en.wikipedia.org/wiki/C_syntax#Primitive_data_types

The c standard have NOT specified the bit-length of primitive data type, but only the least bit-length of them. So compilers can have options on the bit-length of primitive data types. On deciding the bit-length of each primitive data type, the compiler designer should consider the several factors, including the computer architecture.

here is some references:
http://en.wikipedia.org/wiki/C_syntax#Primitive_data_types

冰葑 2024-12-09 17:37:52

了解历史,包括为什么 UNIX 系统通常集中在 LP64 上,以及为什么 Windows 没有(具有 int 16 和 long 32 的大代码库),以及各种论点:
通向 64 位的漫漫长路 - 双重、双重、辛劳和麻烦——莎士比亚、麦克白
https://queue.acm.org/detail.cfm?id=1165766 队列2006
或者
https://dl.acm.org/doi/pdf/10.1145/1435417.1435431 CACM 2009

注:我帮助设计了 64/32 位MIPS R4000,提出了导致的想法,并为 C99 写了很长很长的动机部分。

For the history, including why UNIX systems generally converged on LP64, and why Windows did not (big code base that had int 16 and long 32), and the various arguments:
The Long Road to 64 Bits - Double, double, toil and trouble—Shakespeare, Macbeth
https://queue.acm.org/detail.cfm?id=1165766 Queue 2006
OR
https://dl.acm.org/doi/pdf/10.1145/1435417.1435431 CACM 2009

Note: I helped design the 64/32-bit MIPS R4000, suggested the idea that led to <inttypes.h>, and wrote the long long motivation section for C99.

吐个泡泡 2024-12-09 17:37:52

由于历史原因。很长一段时间(双关语),“int”表示 16 位;因此“长”为 32 位。当然,时代变了。因此“long long”:)

PS:

GCC(和其他)当前支持 128 位整数作为“(u)int128_t”。

PPS:

这里讨论了 GCC 人员为何做出这样的决定:

http://www.x86-64.org/pipermail/discuss/2005-August/006412.html

For historical reasons. For a long time (pun intended), "int" meant 16-bit; hence "long" as 32-bit. Of course, times changed. Hence "long long" :)

PS:

GCC (and others) currently support 128 bit integers as "(u)int128_t".

PPS:

Here's a discussion of why the folks at GCC made the decisions they did:

http://www.x86-64.org/pipermail/discuss/2005-August/006412.html

吲‖鸣 2024-12-09 17:37:52

自从第一个用于通用可重编程微型计算机的 C 编译器问世以来,代码通常需要使用精确保存 8、16 或 32 位的类型,但直到 1999 年标准才明确提供程序可以通过任何方式来指定这一点。另一方面,几乎所有 8 位、16 位和 32 位微计算机的编译器都将“char”定义为 8 位,
“短”为 16 位,“长”为 32 位。它们之间唯一的区别是
“int”是 16 位还是 32 位。

虽然 32 位或更大的 CPU 可以使用“int”作为 32 位类型,但保留“long”
作为 64 位类型可用,有大量代码需要
“长”将是 32 位。虽然 C 标准添加了“固定大小”类型
1999年,标准中还有其他地方仍然使用“int”和
“long”,例如“printf”。虽然 C99 添加了宏来提供正确的格式
固定大小整数类型的说明符,有大量的语料库
代码期望“%ld”是 int32_t 的有效格式说明符,因为
它几乎可以在任何 8 位、16 位或 32 位平台上运行。

出于对
现有的代码库可以追溯到几十年前,或 64 位,以避免需要
用于标识 64 位类型的更详细的“long long”或“int64_t”是
可能是一个判断调用,但考虑到新代码可能应该有利于
在实际情况下使用指定大小的类型,我不确定我是否看到了令人信服的
使“long”为 64 位的优势,除非“int”也是 64 位(这将
现有代码会产生更大的问题)。

Ever since the days of the first C compiler for a general-purpose reprogrammable microcomputer, it has often been necessary for code to make use of types that held exactly 8, 16, or 32 bits, but until 1999 the Standard didn't explicitly provide any way for programs to specify that. On the other hand, nearly all compilers for 8-bit, 16-bit, and 32-bit microcomputers define "char" as 8 bits,
"short" as 16 bits, and "long" as 32 bits. The only difference among them is
whether "int" is 16 bits or 32.

While a 32-bit or larger CPU could use "int" as a 32-bit type, leaving "long"
available as a 64-bit type, there is a substantial corpus of code which expects
that "long" will be 32 bits. While the C Standard added "fixed-sized" types
in 1999, there are other places in the Standard which still use "int" and
"long", such as "printf". While C99 added macros to supply the proper format
specifiers for fixed-sized integer types, there is a substantial corpus of
code which expects that "%ld" is a valid format specifier for int32_t, since
it will work on just about any 8-bit, 16-bit, or 32-bit platform.

Whether it makes more sense to have "long" be 32 bits, out of respect for an
existing code base going back decades, or 64 bits, so as to avoid the need for
the more verbose "long long" or "int64_t" to identify the 64-bit types is
probably a judgment call, but given that new code should probably favor the
use of specified-size types when practical, I'm not sure I see a compelling
advantage to making "long" 64 bits unless "int" is also 64 bits (which will
create even bigger problems with existing code).

柠北森屋 2024-12-09 17:37:52

d 32位微计算机将“char”定义为8位,“short”定义为16位,“long”定义为32位。它们之间唯一的区别是“int”是 16 位还是 32 位。

虽然 32 位或更大的 CPU 可以使用“int”作为 32 位类型,而“long”可用作 64 位类型,但大量代码,预计“long”为 32 位。虽然 C 标准在 1999 年添加了“固定大小”类型,但标准中的其他地方仍然使用“int”和“long”,例如“printf”。虽然 C99 添加了宏来提供

d 32-bit microcomputers define "char" as 8 bits, "short" as 16 bits, and "long" as 32 bits. The only difference among them is whether "int" is 16 bits or 32.

While a 32-bit or larger CPU could use "int" as a 32-bit type, leaving "long" available as a 64-bit type, there is a substantial corpus of code which expects that "long" will be 32 bits. While the C Standard added "fixed-sized" types in 1999, there are other places in the Standard which still use "int" and "long", such as "printf". While C99 added macros to supply the

懒的傷心 2024-12-09 17:37:52

C99 N1256标准草案< /strong>

long 和 long long 的大小是实现定义的,我们所知道的是:

  • 最小大小保证
  • 类型之间的相对大小

5.2.4.2.1 整数类型的大小 给出最小大小:

1 [...]它们的实现定义值的大小(绝对值)应等于或大于所示的值[...]

  • UCHAR_MAX 255 // 2 8 - 1
  • USHRT_MAX 65535 // 2 16 - 1
  • UINT_MAX 65535 // 2 16 - 1
  • ULONG_MAX 4294967295 // 2 32 − 1
  • ULLONG_MAX 18446744073709551615 // 2 64 − 1

6.2.5 类型 然后说:

8 对于任何两个具有相同符号和不同整数转换等级的整数类型
(见6.3.1.1),整数转换等级较小的类型的取值范围为a
其他类型值的子范围。

6.3.1.1 布尔值、字符和整数确定相对转换等级:

1 每个整数类型都有一个整数转换等级,定义如下:

  • long long int 的等级应大于 long int 的等级,即
    应大于 int 的等级,而 int 的等级应大于 Short 的等级
    int,应大于有符号字符的排名。
  • 任何无符号整数类型的等级应等于相应的等级
    有符号整数类型(如果有)。
  • 对于所有整数类型 T1、T2 和 T3,如果 T1 的秩大于 T2 并且 T2 的秩高
    等级高于 T3,则 T1 的等级高于 T3

C99 N1256 standard draft

Sizes of long and long long are implementation defined, all we know are:

  • minimum size guarantees
  • relative sizes between the types

5.2.4.2.1 Sizes of integer types <limits.h> gives the minimum sizes:

1 [...] Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown [...]

  • UCHAR_MAX 255 // 2 8 − 1
  • USHRT_MAX 65535 // 2 16 − 1
  • UINT_MAX 65535 // 2 16 − 1
  • ULONG_MAX 4294967295 // 2 32 − 1
  • ULLONG_MAX 18446744073709551615 // 2 64 − 1

6.2.5 Types then says:

8 For any two integer types with the same signedness and different integer conversion rank
(see 6.3.1.1), the range of values of the type with smaller integer conversion rank is a
subrange of the values of the other type.

and 6.3.1.1 Boolean, characters, and integers determines the relative conversion ranks:

1 Every integer type has an integer conversion rank defined as follows:

  • The rank of long long int shall be greater than the rank of long int, which
    shall be greater than the rank of int, which shall be greater than the rank of short
    int, which shall be greater than the rank of signed char.
  • The rank of any unsigned integer type shall equal the rank of the corresponding
    signed integer type, if any.
  • For all integer types T1, T2, and T3, if T1 has greater rank than T2 and T2 has
    greater rank than T3, then T1 has greater rank than T3
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文