blocks|key|3950326|text|不，在某些平台上只有4个字节。C%2B%2B标准将大小保留为实现定义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3950327|在其他平台上，它可能是不同的大小。|3950328|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

No, it's only 4 bytes on certain platforms. The C++ standard leaves the size as being implementation-defined.

On other platforms it may be a different size.

blocks|key|3467704|text|C%2B%2B标准只规定long至少和int一样大，所以当它完全一样大的时候，在场景中没有什么犯罪:它是完全由实现定义的。在不同的平台上，大小可能很重要，例如，在我的Linux机器上，我的int大小为4，long大小为8。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3467705|entityMap^0|8|4|F|3|2I|3|2Q|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

C++ standard only specifies that <code>long</code> is at least as big as <code>int</code>, so there's nothing criminal in the scenario when it is exactly as big: it's totally implementation-defined. On different platforms, sizes may matter, for example I'm having <code>int</code> of size 4 and <code>long</code> of size 8 at the moment on my Linux machine.

blocks|key|119464|text|我认为它依赖于实现。它们可能会有所不同，但这取决于供应商提供它们。然而，一些供应商只是简单地让它们在语法上得到“支持”(即:你可以将它们放在你的代码中，它们将被编译，但没有什么不同)。有时，您会遇到这样的语言特性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|119465|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think it's implementation dependent. They can vary, but it is up to the vendor to supply them. However, some vendors simply make it so that they are syntactically "supported" (ie: you can put them in your code and they will compile, but don't differ). Every so often, you'll encounter a language feature like this.

blocks|key|3467743|text|它不一定要更大。例如，当我在我的机器上使用时，通常会将long定义为8个字节，这就是GCC的方式。该标准的措辞通常要求这些类型“至少需要X大小”(例如，请查看finally-standardized+long+long+in+C%2B%2B11。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3467744|本质上，只要满足要求，任何人都可以自由地做他们想做的事情。根据标准，有人可以使long+long的256位，这将是完全合法的。|3467745|entityMap|0|LINK|mutability|MUTABLE|url|http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1811.pdf^0|R|4|2S|9|27|13|0|0|13|9|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

It doesn't necesarily have to be larger. It's just the way the GCC, for example, usually has <code>long</code> to be defined as 8 bytes when I've used it on my machine. The standard's wording usually says that these types 'Need to be at least X size' (for an example, check out the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1811.pdf" rel="nofollow">finally-standardized <code>long long</code> in C++11</a>.

Essentially, anyone's free to do what they want as long as it meets the requirements. According to the standard, someone could make <code>long long</code> 256 bits, and it'd be perfectly legal.

blocks|key|119608|text|关于整数类型，唯一能保证的是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|119609|119610|sizeof(char)+==+1+|ordered-list-item|offset|length|style|CODE|119611|sizeof(char)+<=+sizeof(short)+|119612|sizeof(short)+<=+sizeof(int)+|119613|sizeof(int)+<=+sizeof(long)|119614|sizeof(long)+<=+sizeof(long+long)|119615|sizeof(char)+*+CHAR_BIT+>=+8|119616|sizeof(short)+*+CHAR_BIT+>=+16+|119617|sizeof(int)+*+CHAR_BIT+>=+16+|119618|sizeof(long)+*+CHAR_BIT+>=+32|119619|sizeof(long+long)+*+CHAR_BIT+>=+64|119620|119621|其他事情都是由实现定义的。|119622|entityMap^0|0|0|0|H|0|0|T|0|0|S|0|0|R|0|0|X|0|0|S|0|0|U|0|0|S|0|0|T|0|0|Y|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|18|8|@$F|19|G|1A|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|1B|8|@$F|1C|G|1D|H|I]]|9|@]|A|$]]|$1|L|3|M|5|E|7|1E|8|@$F|1F|G|1G|H|I]]|9|@]|A|$]]|$1|N|3|O|5|E|7|1H|8|@$F|1I|G|1J|H|I]]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1K|8|@$F|1L|G|1M|H|I]]|9|@]|A|$]]|$1|R|3|S|5|E|7|1N|8|@$F|1O|G|1P|H|I]]|9|@]|A|$]]|$1|T|3|U|5|E|7|1Q|8|@$F|1R|G|1S|H|I]]|9|@]|A|$]]|$1|V|3|W|5|E|7|1T|8|@$F|1U|G|1V|H|I]]|9|@]|A|$]]|$1|X|3|Y|5|E|7|1W|8|@$F|1X|G|1Y|H|I]]|9|@]|A|$]]|$1|Z|3|10|5|E|7|1Z|8|@$F|20|G|21|H|I]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|23|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|24|8|@]|9|@]|A|$]]]|15|$]]

The only things guaranteed about integer types are:

<ol>
<li><code>sizeof(char) == 1</code> </li>
<li><code>sizeof(char) &lt;= sizeof(short)</code> </li>
<li><code>sizeof(short) &lt;= sizeof(int)</code> </li>
<li><code>sizeof(int) &lt;= sizeof(long)</code></li>
<li><code>sizeof(long) &lt;= sizeof(long long)</code></li>
<li><code>sizeof(char) * CHAR_BIT &gt;= 8</code></li>
<li><code>sizeof(short) * CHAR_BIT &gt;= 16</code> </li>
<li><code>sizeof(int) * CHAR_BIT &gt;= 16</code> </li>
<li><code>sizeof(long) * CHAR_BIT &gt;= 32</code></li>
<li><code>sizeof(long long) * CHAR_BIT &gt;= 64</code></li>
</ol>

The other things are implementation defined. Thanks to (4), both <code>long</code> and <code>int</code> can have the same size, but it must be at least 32 bits (thanks to (9)).

blocks|key|3950525|text|C%2B%2B语言规范简单地规定了long的大小必须至少等于int的大小。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3950526|过去的标准是int+=2字节，long+=4字节。出于某种原因，int成长了，而long保持不变(至少在Windows编译器上是这样)。我只能推测，由于向后兼容的原因，long保持了相同的……|BOLD|3950527|entityMap^0|D|4|Q|3|0|6|3|F|4|W|3|14|4|2C|4|2M|2|0^^$0|@$1|2|3|4|5|6|7|K|8|@$9|L|A|M|B|C]|$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|H]]|D|@]|E|$]]|$1|I|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|J|$]]

The C++ Language Specification simply states that the size of a <code>long</code> must be at least the size of an <code>int</code>.

It used to be standard to have <code>int</code> = 2 bytes and <code>long</code> = 4 bytes. For some reason <code>int</code> grew up and <code>long</code> stayed the same (on Windows compilers at least). I can only speculate that <code>long</code> was kept the same for reasons of backwards compatibility...

blocks|key|5678308|text|正如其他人所指出的那样，这个问题背后的假设只是部分正确的，也就是说，在某些平台上并不成立。如果你真的想了解我们是如何走到现在的境地的，J·马希的the+Long+Road+to+64+Bits将给你一个很好的视角，了解各种力量的存在以及它们是如何相互作用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5678309|快速总结，C从char+(8位)和int+(16位)开始。然后添加了short+(16位)和long+(32位)，而int可以是16位或32位，这取决于平台上的自然特性和向后兼容的压力。当64位出现时，long+long被添加为64位类型，并且在64位平台上对较小的类型进行了一些调整。32位int稳定了下来，但long保持了各种定义，一些64位平台有64位long，而另一些(可能只有Windows?)将long保持为32位，可能是由于向后兼容性的不同压力(Unix长期以来一直将long假定为与指针相同的大小，当int为16位时，Windows中的残留更多，因此long是唯一的32位类型)。顺便说一句，添加typedefs+(intXX_t，intptr_t)是为了帮助使意图更清晰，但对于intXX_t家族来说，强制不变的大小是不真正需要的。|style|CODE|5678310|entityMap|0|LINK|mutability|MUTABLE|url|http://queue.acm.org/detail.cfm?id=1165766^0|20|O|0|0|7|4|H|3|Y|5|1A|4|1M|3|2T|9|42|3|4C|4|4Z|4|5N|4|6P|4|76|3|7V|4|8S|7|90|8|9O|7|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@$A|U|B|V|F|G]|$A|W|B|X|F|G]|$A|Y|B|Z|F|G]|$A|10|B|11|F|G]|$A|12|B|13|F|G]|$A|14|B|15|F|G]|$A|16|B|17|F|G]|$A|18|B|19|F|G]|$A|1A|B|1B|F|G]|$A|1C|B|1D|F|G]|$A|1E|B|1F|F|G]|$A|1G|B|1H|F|G]|$A|1I|B|1J|F|G]|$A|1K|B|1L|F|G]|$A|1M|B|1N|F|G]|$A|1O|B|1P|F|G]]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1Q|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

As other have pointed out, the assumption underlying the question is only partially true, i.e. doesn't hold for some platforms. If you really want to understand how we came to the current situation, <a href="http://queue.acm.org/detail.cfm?id=1165766" rel="noreferrer">the Long Road to 64 Bits</a> by J. Mashey will give you a good view on the various forces in presence and how they interacted.

Quick summary, C started with <code>char</code> (8 bits) and <code>int</code> (16 bits). Then one added <code>short</code> (16 bits) and <code>long</code> (32 bits), while <code>int</code> could be 16 or 32 bits depending on what was natural on the platform and the pressure of backward compatibility. When 64 bits came, <code>long long</code> was added as a 64 bits type and there was some adjustments in the smaller types on 64 bits platforms. Things stabilized with a 32 bits <code>int</code>, but <code>long</code> kept various definitions, some 64 bits platforms having a 64 bits <code>long</code>, while other (perhaps only Windows?) kept <code>long</code> to 32 bits, probably due to different pressure of backward compatibility (Unix had a long history of assuming <code>long</code> as the same size as a pointer, Windows had more remnant in its API of the time when <code>int</code> was 16 bits and thus <code>long</code> was the only 32 bits type). BTW typedefs (<code>intXX_t</code>, <code>intptr_t</code>) were added to help to make the intention clearer, at the risk for the <code>intXX_t</code> family to force constant size were none is really needed.

blocks|key|119695|text|没有人回答你的实际问题，也许除了AProgrammer。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|119696|C/C%2B%2B标准的定义如Griwes所述。这允许实现C和C%2B%2B语言，其中编译器供应商可以定义对计算机体系结构最方便的大小。有一段时间(对于Windows3.1和更早的版本，即在Windows95之前)，Windows的C代码使用16位int，而许多UNIX平台，如Solaris、HPUX和AIX都使用32位int。|119697|然而，现代微型计算机(从386开始)具有完整的32位寄存器，并且寻址对齐到32位的存储器比访问16位增量快得多。因此，使用32位int比使用16位int要高效得多，尤其是对于int数组。|119698|要在32位寄存器中模拟16位整数，还必须在第16位而不是第32位溢出。所以使用32位int会更简单，即使你只有32位可用很长时间。|119699|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

No one has answered your actual question, except maybe AProgrammer.

The C/C++ standard is defined as Griwes described. This allows the C and the C++ language to be implemented where the compiler vendor can define the sizes most convenient to the computer architecture. For a while, (for Windows 3.1 and before, that is, before Windows 95), C code for windows had a 16 bit int whereas many UNIX platforms, such as Solaris, HPUX, and AIX had a 32 bit int.

However, modern microcomputers (since the 386), have full 32 bit registers, and addressing memory aligned to 32 bits is much faster then accessing 16 bit increments. Thus code is much more efficient with a 32 bit int, especially for int arrays, than it might be with a 16 bit int.

To simulate a 16 bit int in a 32 bit register, you also have to overflow at the 16th bit, instead of the 32nd. So it's just easier with a 32 bit int, even if you only have 32 bits available for long.

Many sources, including <a href="http://msdn.microsoft.com/en-us/library/s3f49ktz%28v=vs.80%29.aspx" rel="noreferrer">Microsoft</a>, reference both the int and long type as being 4 bytes and having a range of (signed) -2,147,483,648 to 2,147,483,647. What is the point of having a long primitive type if it doesn't actually provide a larger range of values?

Why are C++ int and long types both 4 bytes?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

包括在内的许多来源都将int和long类型引用为4字节，并且具有(signed) -2,147,483,648到2,147,483,647的范围。如果long原语类型实际上没有提供更大范围的值，那么它有什么意义呢？

问为什么C++的int和long类型都是4字节？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么C++的int和long类型都是4字节？EN