整数中的每个字节如何存储在CPU/内存中？
我已经尝试过，
char c[4];
int i=89;
memcpy(&c[0],&i,4);
cout<<(int)c[0]<<endl;
cout<<(int)c[1]<<endl;
cout<<(int)c[2]<<endl;
cout<<(int)c[3]<<endl;
输出如下：
89
0
0
0
这非常训练我的胃，因为我认为这个数字会像这样保存在内存中 0x00000059 那么为什么 c[0] 是 89 ？我认为它应该在 c[3] 中......
i have tried this
char c[4];
int i=89;
memcpy(&c[0],&i,4);
cout<<(int)c[0]<<endl;
cout<<(int)c[1]<<endl;
cout<<(int)c[2]<<endl;
cout<<(int)c[3]<<endl;
the output is like:
89
0
0
0
which pretty trains my stomache cuz i thought the number would be saved in memory like
0x00000059 so how come c[0] is 89 ? i thought it is supposed to be in c[3]...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
因为您运行的处理器是 little-endian。多字节基本类型的字节顺序被交换。在大端机器上，它会如您所期望的那样。
Because the processor you are running on is little-endian. The byte order, of a multi-byte fundamental type, is swapped. On a big-endian machine it would be as you expect.
这是因为您在 little endian CPU 上运行该程序。另请参阅此处和那里。
This is because you're running the program on a little endian cpu. See also endianness here and there.
正如戈兹所指出的，字节序显然是答案。
但对于那些不清楚这意味着什么的人来说，了解示例中显示的字节顺序与原始 int 中的顺序相同也很重要。无论平台的 edian 类型如何，Memcpy 都不会更改字节顺序。
Endian-ness is obviously the answer as Goz has pointed out.
But for those who are unclear of what that means, it's also important to understand that the order of bytes displayed in the example is the same as the order in the original int. Memcpy doesn't change the byte order, regardless of the edian type of the platform.
因为字节顺序是任意设计决策。一旦进入寄存器，就没有字节顺序1。
当我们寻址较小的单位（例如字节）时，就会出现字节顺序。这本质上是 CPU 设计者做出的任意决定：大端还是小端。
简化情况并认识到主要是与外设的连接是字节排序的，这很有用。是的，正如您所证明的那样，可以通过字节寻址发现它，但一般来说，标量值作为单元加载并存储到寄存器中，在这种情况下，字节顺序不会改变任何内容。最重要的位位于“左边”，至少是我们通常写数字的方式。这就是为什么根据语言标准使用时
<<和>>运算符在大端和小端机器上总是产生完全相同的结果。但是为了向外围设备读取和写入数据流，您必须选择字节顺序。这是因为外设本质上是字节流设备。最低地址有最高有效位还是最低有效位？这是双向的，营地的划分相当均匀。
因为内存本身是字节寻址的，所以在没有外围设备的情况下当然可以导出不同的行为，但是如果没有像您那样刻意查看内部，这通常不会发生。
想象一下一个没有字节，只有 32 位字的 CPU，寻址为 0、1、2。C 编译器将 char、int 和 long 都设为 32 位对象。 （这是 Cx9 允许的。）哇，没有字节顺序问题！两者都是！但是..当我们连接第一个外围设备时会发生什么？
1.嗯，x86 的寄存器可以为较小的寄存器起别名，但那是另一个故事了。
Because byte order is an arbitrary design decision. Once in a register, there is no byte order1.
Byte order arises when we address smaller units like bytes. It's an essentially arbitrary decision the CPU designer gets to make: big-endian or little-endian.
It's useful to simplify the situation and realize that it is mainly the connection to peripherals that is byte ordered. Yes, it can be discovered via byte addressing as you have proved, but in general scalar values are loaded and stored as units, into registers, and in this case byte order doesn't change anything. The most significant bits are on "the left", at least, the way we usually write numbers. And that's why the
<<and>>operators always produce the exact same results on big-endian vs little-endian machines when used according to the language standards.But in order to read and write data streams to peripheral devices, you are forced to choose a byte order. This is because peripherals are fundamentally byte stream devices. Does the lowest address have the most significant bits or the least? It's done both ways and the camps used to be rather evenly divided.
Because memory itself is byte addressed, it's certainly possible to derive different behavior without a peripheral, but this typically doesn't happen without a deliberate peek inside like you did.
Imagine a CPU that has no bytes, only 32-bit words, addressed as 0, 1, 2. The C compiler makes char, int, and long all 32-bit objects. (This is allowed by Cx9.) Wow, no byte order issues! It's both! But .. what happens when we hook up our first peripheral??
1.Well, x86 has registers that alias smaller registers, but that's another story.
不同的机器可以有不同的字节顺序，但看一下这段代码并想想会发生什么，具体取决于字节的布局方式：
Different machines can have different byte ordering, but take a look at this code and think about what happens, depending on how the bytes are laied out:
如果您希望您的应用程序可移植或在团队内开发，您可能不想遵循此逻辑，因为这会导致难以捕获错误并延长开发时间。
If you want your application to be portable or developed within a team, you probably don't want to follow this logic as it would cause hard to catch bugs and prolong development.