为什么本地数组末尾有多余的空位置(c/c++/gcc)?
检查下面的程序,
int main()
{
short int data1[]={1,2,3,4,5,6,7,8,9,10};
short int data2[]={1,2,3,4,5,6,7,8,9,10};
short int *ptr = data1;
cout<<"data1 start addr = "<<data1<<endl;
cout<<"data2 start addr = "<<data2<<endl;
for (int i=0;i<20;i++, ptr++)
cout <<"Data = "<<*ptr<<" Addr = "<<ptr<<endl;
return 0;
}
在上面的程序中,即使数组大小为 10,在第一个数组之后,在堆栈中保留了 6 个额外的位置(12 字节), 我想知道为什么要保留这个额外的空间?并且这个额外的空间大小对于不同的尺寸是不同的(对于尺寸 20 来说不是 12)。 有人可以解释这些分配背后的概念吗?
使用 g++/gcc 的上述程序的输出是,
data1 start addr = 0x7ffc87350920
data2 start addr = 0x7ffc87350940
Data = 1 Addr = 0x7ffc87350920
Data = 2 Addr = 0x7ffc87350922
Data = 3 Addr = 0x7ffc87350924
Data = 4 Addr = 0x7ffc87350926
Data = 5 Addr = 0x7ffc87350928
Data = 6 Addr = 0x7ffc8735092a
Data = 7 Addr = 0x7ffc8735092c
Data = 8 Addr = 0x7ffc8735092e
Data = 9 Addr = 0x7ffc87350930
Data = 10 Addr = 0x7ffc87350932
Data = 32629 Addr = 0x7ffc87350934
Data = 0 Addr = 0x7ffc87350936
Data = 9232 Addr = 0x7ffc87350938
Data = 12176 Addr = 0x7ffc8735093a
Data = 22064 Addr = 0x7ffc8735093c
Data = 0 Addr = 0x7ffc8735093e
Data = 1 Addr = 0x7ffc87350940
Data = 2 Addr = 0x7ffc87350942
Data = 3 Addr = 0x7ffc87350944
Data = 4 Addr = 0x7ffc87350946
Check below program,
int main()
{
short int data1[]={1,2,3,4,5,6,7,8,9,10};
short int data2[]={1,2,3,4,5,6,7,8,9,10};
short int *ptr = data1;
cout<<"data1 start addr = "<<data1<<endl;
cout<<"data2 start addr = "<<data2<<endl;
for (int i=0;i<20;i++, ptr++)
cout <<"Data = "<<*ptr<<" Addr = "<<ptr<<endl;
return 0;
}
In the above program, even though array size is 10, after the first array there is exactly 6 extra locations reserved in the stack (12bytes), I am wondering why this extra space got reserved? and this extra space size is varying for different size(Its not 12 for size 20).
Can anybody explain the concept behind these allocations?
Output of above program using g++/gcc is,
data1 start addr = 0x7ffc87350920
data2 start addr = 0x7ffc87350940
Data = 1 Addr = 0x7ffc87350920
Data = 2 Addr = 0x7ffc87350922
Data = 3 Addr = 0x7ffc87350924
Data = 4 Addr = 0x7ffc87350926
Data = 5 Addr = 0x7ffc87350928
Data = 6 Addr = 0x7ffc8735092a
Data = 7 Addr = 0x7ffc8735092c
Data = 8 Addr = 0x7ffc8735092e
Data = 9 Addr = 0x7ffc87350930
Data = 10 Addr = 0x7ffc87350932
Data = 32629 Addr = 0x7ffc87350934
Data = 0 Addr = 0x7ffc87350936
Data = 9232 Addr = 0x7ffc87350938
Data = 12176 Addr = 0x7ffc8735093a
Data = 22064 Addr = 0x7ffc8735093c
Data = 0 Addr = 0x7ffc8735093e
Data = 1 Addr = 0x7ffc87350940
Data = 2 Addr = 0x7ffc87350942
Data = 3 Addr = 0x7ffc87350944
Data = 4 Addr = 0x7ffc87350946
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您不能期望项目在堆栈上分配的顺序与它们在代码中定义的顺序相匹配,除非您显式指定字段应如何相对于彼此存储的结构。出于性能或其他原因,编译器可以并且确实会对元素进行重新排序。
如果不检查组件以了解它们是如何使用的,就无法确定这些项目是什么。读取它们是未定义的行为,因为您无法在编译时判断它们是什么,或者它们是否代表有效内存,因为它超出了您定义的任何变量的范围。但很可能,它们只是程序中的其他变量。
You can't expect the order that items will be allocated on the stack matches the order they are defined in code unless you explicitly specify a structure for how fields should be stored relative to each other. The compiler can and does reorder elements for performance or other reasons.
There is no way to tell for sure what those items are without checking the assembly to see how they get used. Reading them is undefined behavior since you can't tell at compile time what they will be, or if they will even represent valid memory since it is outside of the bounds of any of the variables you defined. Odds are, they are just other variables in your program though.