int的大小是否取决于编译器和/或处理器?

整数的大小取决于编译器,操作系统和处理器?

这个问题的答案取决于我们愿意得到多less实际考虑。

最终,从理论上讲,C和C ++中的所有内容都依赖于编译器,而只依赖于编译器。 硬件/操作系统根本不重要。 编译器可以自由地实现任何厚度的硬件抽象层,并且可以模拟任何东西。 只要C或C ++实现的大小足以满足语言标准中规定的最低要求,就没有什么可以阻止C或C ++实现实现任何大小的inttypes和任何表示forms。 这种抽象级别的实际例子是容易获得的,例如基于“虚拟机”平台的编程语言,如Java。

但是,C和C ++旨在成为高效的语言。 为了达到最高的效率,C或C ++的实现必须考虑到底层硬件的某些考虑因素。 出于这个原因,确保每个基本types都是基于硬件直接(或几乎直接)支持的某种表示forms是非常有意义的。 从这个意义上讲,基本types的大小取决于硬件。

换句话说,64位硬件/操作系统平台的一个特定的C或C ++实现完全可以自由实现int作为占用128位内存的71位1的补码有符号整型,使用其他57位作为填充总是需要存储编译器作者的女朋友的出生date的位。 这个实现甚至会有一定的实用价值:它可以用来执行C / C ++程序的可移植性的运行时testing。 但是这就是实施的实际用处将会结束的地方。 不要指望在“普通”的C / C ++编译器中看到类似的东西。

是的,这取决于两个处理器(更具体地说,ISA,指令集架构,例如x86和x86-64)以及包括编程模型的编译器。 例如,在16位机器中,sizeof(int)是2个字节。 32位机器有4个字节的int 。 一直认为int是处理器的本地大小,即寄存器的大小。 但是,32位计算机非常stream行,并且已经为32位编程模型编写了大量的软件。 所以,如果64位计算机有8个字节的int ,那将是非常混乱的。 对于int Linux和Windows都保留4个字节。 但是,它们的long

请大家看看64位的编程模型,比如大多数* nix的LP64和Windows的LLP64

当你编写可以在Window和Linux上工作的代码时,这种差异实际上是相当尴尬的。 所以,我总是通过stdint.h使用int32_tint64_t ,而不是long

是的,会的。 他们的意思是“哪一个取决于:编译器还是处理器”? 在这种情况下,答案基本上是“两个”。 通常情况下, int不会比处理器寄存器大(除非它小于16位),但可能会更小(例如,在64位处理器上运行的32位编译器)。 但是,通常情况下,您将需要一个64位处理器来运行64位int的代码。

基于最近的一些研究,我已经完成了对固件访问的研究:

处理器位架构(即8位,16位,32位,64位)的最重要的影响是您如何最有效地存储每个字节的信息,以便以最less的周期数计算最佳值。

处理器的位大小告诉你CPU在一个周期内能够处理的自然字长度。 如果一个32位机器在内存中正确alignment,则需要2个周期才能处理64位双精度数据。 大多数的个人电脑都是32位的,因此C编译器最可能的原因是32位整数具有更大的浮点数和长整数的选项。

显然你可以计算更大的variables大小,所以在这个意义上,CPU的位结构决定了它将如何存储更大和更小的variables,以达到最好的处理效率,但它决不是限制字节大小整数或字符,这是编译器的一部分,什么是由公约或标准决定的。

我发现这个站点对于解释CPU的自然字长是如何select存储和处理更大更小的variablestypes是非常有用的,特别是关于位打包进入结构。 您必须非常清楚您如何select分配variables,因为较大的variables需要在内存中alignment,因此,除以CPU的字长,它们将占用最less的周期数。 如果您对variables赋值的顺序不正确,那么会在结构体中添加大量可能不必要的缓冲区/空白空间。

简单而正确的答案是它依赖于编译器。 这并不意味着架构是不相关的,但编译器处理,而不是你的应用程序。 你可以更准确地说,它取决于编译器的(目标)体系结构,例如它的32位或64位。

考虑你有Windows应用程序创build一个文件,它写入一个int加上其他的东西,然后读回来。 如果你在32位和64位的窗口上运行,会发生什么? 如果复制在32位系统上创build的文件并在64位系统中打开它,会发生什么情况?

你可能会认为int的大小在每个文件中会有所不同,但是不会是相同的,这就是问题的关键。 您可以select编译器中的设置来指定32位或64位体系结构,并指定所有内容。

数据types大小取决于处理器,因为编译器想让CPU更容易访问下一个字节。 例如:如果处理器是32位,编译器可能不会selectint大小为2字节[它应该select4字节],因为访问该int的另外2个字节(4字节)将需要额外的CPU周期,这是浪费。 如果编译器selectint作为4个字节,CPU可以一次访问完整的4个字节,从而加快应用程序的速度。

谢谢

int的大小等于依赖于底层ISA的字长。 处理器就是ISA的硬件实现,编译器就是ISA的软件端实现。 一切都围绕着底层的ISA。 目前最受欢迎的ISA是Intel的IA-32。 它有一个32位或4字节的字长。 4个字节可以是'int'的最大大小(只是简单的int,而不是长或短)编译器。 基于IA-32,可以使用。

数据types的大小主要取决于编译器的types,编译器是基于处理器的体系结构devise的,所以外部的数据types可以被认为是编译器相关的。对于整数的实际大小,在16位tc编译器中是2字节,而是4字节在gcc编译器中,尽pipe它们在相同的处理器中执行

http://www.agner.org/optimize/calling_conventions.pdf

“3数据表示”包含了编译器用整型types所做的很好的概述。

是的,我发现turbo C中的int大小是2个字节,在MSVC编译器中是4个字节。

基本上int的大小是处理器寄存器的大小。