c/c++ 中的 unsigned long/long/int 有什么区别?

发布于 2024-08-27 08:36:17 字数 38 浏览 6 评论 0原文

好像都占用4个字节的空间,

那么有什么区别呢?

It seems all of them take 4 bytes of space,

so what's the difference?

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

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

发布评论

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

评论(3

羞稚 2024-09-03 08:36:18

首先,int/long 的大小是未指定的。因此,在您的编译器上,intlong 可能是相同的,但这在编译器中并不通用。

至于unsigned longlong的区别:

假设4个字节,一个long的范围是-2,147,483,6482,147,483,647。无符号长整型的范围为 04,294,967,295

另一个区别是溢出。对于有符号类型,溢出具有未指定的行为。但对于无符号类型,溢出肯定会“环绕”。

First of all, the size of int/long is unspecified. So on your compiler, an int and a long might be the same, but this isn't universal across compilers.

As for the difference between unsigned long and long:

Assuming 4 bytes, a long has the range of -2,147,483,648 to 2,147,483,647. An unsigned long has the range of 0 to 4,294,967,295.

One other difference is with overflow. For a signed type, an overflow has unspecified behavior. But for an unsigned type, overflow is guaranteed to "wrap around."

楠木可依 2024-09-03 08:36:18

C 语言规范允许 int 和 long 类型的实现在一些限制内因平台而异。这种可变性对于跨平台代码来说是一个令人头痛的问题,但它也是一种资产,因为它使知情的程序员能够在本机处理器速度和不提供这两种功能的硬件架构上的完整数值范围之间平衡其设计目标。

一般来说,“int”应该映射目标CPU架构机器的机器寄存器大小,因此对int类型数据的加载、存储和操作应该直接转换为使用目标处理器本机寄存器的操作。

Int 可以小于机器寄存器大小,以节省内存空间(大整数占用的 RAM 是小整数的两倍)。即使在 64 位体系结构中,将 int 视为 32 位实体也很常见,其中与旧系统的兼容性和内存效率是重中之重。

“long”的大小可以与“int”相同或更大,具体取决于目标体系结构的寄存器大小。如果目标体系结构不支持其本机机器寄存器中那么大的值,则可以在软件中实现“long”操作。

如今,在专为节能或嵌入式设备而设计的 CPU 芯片中,您会发现 int 和 long 之间的区别。用于通用 CPU(例如台式机或笔记本电脑)的编译器通常将 int 和 long 视为相同的大小,因为 CPU 有效地使用 32 位寄存器。在手机等较小的设备上,CPU 可能会更自然地处理 16 位数据,但必须努力处理 32 位或更大的数据。

每个寄存器的位数更少意味着芯片上需要的电路更少,用于将数据移入和移出芯片的数据线更少,功耗更低,芯片尺寸更小,所有这些都有助于降低设备成本(以美元和瓦为单位) 。

在这样的架构中,您很可能会发现 int 的大小为 16 位,long 的大小为 32 位。还可能存在与使用 long 相关的性能损失,这是由于在 16 位数据总线上的多次读取中加载 32 位的等待状态引起的,或者是由于在软件中实现长操作(加法、减法等)引起的(如果本机)硬件不支持硬件中的此类操作。

作为一般规则,关于 int 和 long 唯一可以假设的是,在任何体系结构上 int 的范围应始终小于或等于 long。您还应该假设有一天您的代码将针对不同的体系结构进行重新编译,其中您当前在 int 和 long 之间看到的任何关系都不再存在。

这就是为什么即使在日常编码中也应该小心地将整型与长型分开。今天它们可能是完全分配兼容的,因为它们对于当前硬件平台的实现细节是一致的,但不能保证在所有平台上都一致。

The C language specification allows the implementation of int and long types to vary from one platform to another within a few constraints. This variability is a headache for cross-platform code, but it is also an asset because it enables the informed programmer to balance their design goals between native processor speed and full numeric range on hardware architectures that don't offer both.

In general, "int" is supposed to map a machine register size of the target CPU architecture's machine, so that loading, storing, and operating on the int type data should translate directly into operations that use the target processor's native registers.

Int can be less than the machine register size in the interest of saving memory space (big ints take up twice as much RAM as little ints). It's common to see int as a 32 bit entity even on 64 bit architectures where compatibility with older systems and memory efficiency are high priorities.

"long" can be the same size or larger than "int" depending on the target architecture's register sizes. Operations on "long" may be implemented in software if the target architecture doesn't support values that large in its native machine registers.

CPU chips designed for power efficiency or embedded devices are where you will find distinctions between int and long these days. Compilers for general purpose CPUs like in your desktop or laptop PC generally treat int and long as the same size because the CPU efficiently uses 32 bit registers. On smaller devices such as cell phones the CPU may be built to handle 16 bit data more naturally and have to work hard to handle 32 bit or larger data.

Fewer bits per register means fewer circuits required on the chip, fewer data lines to move data in and out of the chip, lower power consumption and smaller chip die size, all of which make for a lower cost (in $ and in watts) device.

In such an architecture, you will most likely find int to be 16 bits in size and long to be 32 bits in size. There may also be a performance penalty associated with using longs, caused by either wait states to load the 32 bits in multiple reads across a 16 bit data bus, or caused by implementing long operations (addition, subtraction, etc) in software if the native hardware doesn't support such operations in hardware.

As a general rule, the only thing you can assume about ints and longs is that the range of int should always be less than or equal to long on any architecture. You should also assume that someday your code will be recompiled for a different architecture where whatever relationship you currently see between int and long no longer exists.

This is why you should be careful to keep ints separate from longs even in everyday mundane coding. They may be completely assignment compatible today because their implementation details for your current hardware platform coincide, but that coincidence is not guaranteed across all platforms.

桜花祭 2024-09-03 08:36:18

嗯,unsigned longlong 之间的区别很简单——上限。有符号长整型(在平均 32 位系统上)的范围约为 -21 亿 (-2^31) 到 +21 亿 (+2^31 - 1),而无符号长整型< /code> 从 0 到 42 亿 (2^32 - 1)。

碰巧在许多编译器和操作系统(显然包括您的)上,int 也是一个 32 位值。但 C++ 标准并未确定任何这些类型的最大宽度,仅确定最小宽度。在某些系统上,int 是 16 位。在某些系统上,long 是 64 位。这在很大程度上取决于目标处理器架构及其基本字大小。

头文件 limits.h 的存在是为了定义当前编译环境下各种类型的最大容量,而 stdint.h 的存在是为了提供与环境无关的类型的保证宽度,例如int32_t

Well, the difference between unsigned long and long is simple -- the upper bound. Signed long goes from (on an average 32-bit system) about -2.1 billion (-2^31) to +2.1 billion (+2^31 - 1), while unsigned long goes from 0 to 4.2 billion (2^32 - 1).

It so happens that on many compilers and operating systems (including, apparently, yours), int is also a 32-bit value. But the C++ standard doesn't determine maximum widths for any of these types, only minimum widths. On some systems, int is 16 bits. On some systems, long is 64 bits. A lot of it depends on the processor architecture being targeted, and what its base word size is.

The header limits.h exists to define the maximum capacity of the various types under the current compilation environment, and stdint.h exists to provide environment-independent types of guaranteed width, such as int32_t.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文