刚刚在OSX上发现了这一点,我发现它很好奇,因为我预计它会比int更大。 有没有什么好的理由让它们大小相同?
答案 0 :(得分:14)
这是C和C ++语言规范中大小定义松散的结果。我相信C具有特定的最小尺寸,但C ++中唯一的规则是:
1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
此外,sizeof(int)
和sizeof(long)
在所有平台上的大小不同。我使用过的每个64位平台都有long
符合自然字大小,32位架构为32位,64位架构为64位。
答案 1 :(得分:8)
int
本质上是最方便有效的整数类型 long
是最大整数类型 short
是最小整数类型 如果最长整数类型也最有效,则int
与long
相同。不久之前(想想32位前),{16}位于多个平台上{16}是最宽的自然整数。
答案 2 :(得分:3)
int应该是架构的自然字大小。在过去,在原始IBM PC等16位机器上,整数为16位,长整数为32位。在像68000系列这样的32位机器上,整数仍然是“自然字大小”,现在是32位,长期保持在32位。随着时间的推移,多头增长到64位,然后我们开始使用像英特尔酷睿2这样的64位架构,所以我希望int迟早会增长到64位。
有趣的事实:在我的笔记本电脑上,使用Core 2 Duo和Mac OS X 10.5,int和long都是32位。在我的Linux机器上,还有一个Core 2 Duo和Ubuntu,int是32位,长是64位。
多年前,我在求职面试中被问到,在你添加3之后会有一个int指针。我回答了“3次sizeof(int)过去现在的位置”。面试官逼我,我说这将取决于架构,因为(当时)Windows使用16位整数,但由于我在做Unix编程,我更习惯于32位整数。我没有得到这份工作 - 我怀疑面试官不喜欢我比他更了解的事实。
答案 3 :(得分:3)
正如Tom正确指出的那样,C ++中唯一标准的大小是char,其大小为1(*)。从那以后,类型之间只有“不小于”的关系。大多数人会声称它取决于架构,但更多的是编译器/操作系统决策。运行MacOSX,Windows(32/64位)或Linux(32/64)的相同硬件对于相同的数据类型将具有不同的大小。同一架构和 OS中的不同编译器可以具有不同的大小。即使是相同硬件上相同操作系统上的完全相同的编译器也可能具有不同的大小,具体取决于编译标志:
$ cat test.cpp
#include <iostream>
int main()
{
std::cout << "sizeof(int): " << sizeof(int) << std::endl;
std::cout << "sizeof(long): " << sizeof(long) << std::endl;
}
$ g++ -o test32 test.cpp; ./test32
sizeof(int): 4
sizeof(long): 4
$ g++ -o test64 test.cpp -m64; ./test64
sizeof(int): 4
sizeof(long): 8
这是在MacOSX Leopard上使用gcc编译器的结果。正如您所看到的,硬件和软件是相同的,但是在同一代码中生成的两个可执行文件的大小确实不同。
如果您的代码取决于大小,那么最好不要使用默认类型,而是使用特定类型的编译器使大小明确。或者使用一些提供该支持的可移植库,作为ACE的示例:ACE_UINT64将是64位的无符号整数类型,无论编译器/ os /架构如何。该库将检测编译器和环境,并在每个平台上使用适当的数据类型。
(*)我已经重新检查了C ++标准3.9.1:char size应该'足够大,可以存储实现的基本字符集的任何成员'。后面的:5.3.3: sizeof(char),sizeof(signed char)和sizeof(unsigned char)是1 ,所以是的,char的大小是1个字节。
在阅读其他答案后,我发现一个说明bool是最小的整数类型。同样,标准在需求中是松散的,并且只表示它可以表示 true 和 false 但不是它的大小。标准是明确的:5.3.3,脚注:“sizeof(bool)不要求为1”。
请注意,由于其他原因,某些C ++实现已决定使用大于1个字节的bool。在带有gcc的Apple MacOSX PPC系统中,sizeof(bool)==4
。
答案 4 :(得分:1)
int
和long
并不总是相同的大小,因此不要假设它们在代码中。从历史上看,有8位和16位,以及更熟悉的32位和64位架构。对于嵌入式系统,较小的字大小仍然很常见。在网上搜索ILP32和LP64的信息太多了。