全局/静态变量内存布局

gifty — Sat, 07 May 2011 07:52:00 GMT

��试�E�序�Q?/h3>
#include
#include
using namespace std;
static int gs_num[53];
char g_buf1[190];
char g_buf2[232];
char g_buf3[] = "That's really a test!";
static char gs_buf1[233];
class Base
{
public:
Base()
{
memset(buf, 1, 100);
}
~Base()
{
}
private:
char buf[100];
};
Base g_base;
static Base gs_base;
void func()
{
static int s1[10];
static char s2[16] = "fs";
static int s3[20] = {15};
s1[10] = 3;
int a = s1[0]+ s2[0];
}
int main()
{
static int a[10] = {3};
static int b[10] = {4};
//func();
static Base base;
static char temp[100];
static char temp1[39];
static Base base1;
int c = a[0] + b[0];
cout<gs_buf1[0] = 'a';
return 0;
}

内存布局

在main入口处设�|�断点后内存布局如下�Q?

0x8049160 : 1952540756 1914729255 1819042149 543236217

0x8049170 : 1953719668 33 0 0

0x8049180 <_ZZ4mainE1b>: 4 0 0 0

0x8049190 <_ZZ4mainE1b+16>: 0 0 0 0

0x80491a0 <_ZZ4mainE1b+32>: 0 0 0 0

0x80491b0: 0 0 0 0

0x80491c0 <_ZZ4mainE1a>: 3 0 0 0

0x80491d0 <_ZZ4mainE1a+16>: 0 0 0 0

0x80491e0 <_ZZ4mainE1a+32>: 0 0 29542 0

0x80491f0 <_ZZ4funcvE2s2+8>: 0 0 0 0

0x8049200 <_ZSt4cout@@GLIBCXX_3.4>: 3086816908 3086816928 6 0

0x8049210 <_ZSt4cout@@GLIBCXX_3.4+16>: 4098 0 0 0

0x8049220 <_ZSt4cout@@GLIBCXX_3.4+32>: 0 0 0 0

0x8049230 <_ZSt4cout@@GLIBCXX_3.4+48>: 0 0 0 0

0x8049240 <_ZSt4cout@@GLIBCXX_3.4+64>: 0 0 0 0

0x8049250 <_ZSt4cout@@GLIBCXX_3.4+80>: 0 0 0 0

0x8049260 <_ZSt4cout@@GLIBCXX_3.4+96>: 0 0 8 134517288

0x8049270 <_ZSt4cout@@GLIBCXX_3.4+112>: 3086833084 0 0 3086827968

0x8049280 <_ZSt4cout@@GLIBCXX_3.4+128>: 3086829728 3086830428 3086830420 0

0x8049290 : 0 0 0 0

0x80492a0 : 0 0 0 0

0x80492b0 : 0 0 0 0

0x80492c0 : 0 0 0 0

0x80492d0 : 0 0 0 0

0x80492e0 : 0 0 0 0

0x80492f0 : 0 0 0 0

0x8049300 : 0 0 0 0

0x8049310 : 0 0 0 0

0x8049320 : 0 0 0 0

0x8049330 : 0 0 0 0

0x8049340 : 0 0 0 0

0x8049350 : 0 0 0 0

0x8049360 : 0 0 0 0

0x8049370 : 0 0 0 0

0x8049380 : 0 0 0 0

0x8049390 : 0 0 0 0

0x80493a0 : 0 0 0 0

0x80493b0 : 0 0 0 0

0x80493c0 : 0 0 0 0

0x80493d0 : 0 0 0 0

0x80493e0 : 0 0 0 0

0x80493f0 : 0 0 0 0

0x8049400 : 0 0 0 0

0x8049410 : 0 0 0 0

0x8049420 : 0 0 0 0

0x8049430 : 0 0 0 0

0x8049440 : 0 0 0 0

0x8049450: 0 0 0 0

0x8049460 : 16843009 16843009 16843009 16843009

0x8049470 : 16843009 16843009 16843009 16843009

0x8049480 : 16843009 16843009 16843009 16843009

0x8049490 : 16843009 16843009 16843009 16843009

0x80494a0 : 16843009 16843009 16843009 16843009

0x80494b0 : 16843009 16843009 16843009 16843009

0x80494c0 : 16843009 0 0 0

0x80494d0: 0 0 0 0

0x80494e0 <_ZL7gs_base>: 16843009 16843009 16843009 16843009

0x80494f0 <_ZL7gs_base+16>: 16843009 16843009 16843009 16843009

0x8049500 <_ZL7gs_base+32>: 16843009 16843009 16843009 16843009

0x8049510 <_ZL7gs_base+48>: 16843009 16843009 16843009 16843009

0x8049520 <_ZL7gs_base+64>: 16843009 16843009 16843009 16843009

0x8049530 <_ZL7gs_base+80>: 16843009 16843009 16843009 16843009

0x8049540 <_ZL7gs_base+96>: 16843009 0 0 0

0x8049550 <_ZGVZ4mainE5base1>: 0 0 0 0

0x8049560 <_ZL7gs_buf1>: 0 0 0 0

0x8049570 <_ZL7gs_buf1+16>: 0 0 0 0

0x8049580 <_ZL7gs_buf1+32>: 0 0 0 0

0x8049590 <_ZL7gs_buf1+48>: 0 0 0 0

0x80495a0 <_ZL7gs_buf1+64>: 0 0 0 0

---Type to continue, or q to quit---

0x80495b0 <_ZL7gs_buf1+80>: 0 0 0 0

0x80495c0 <_ZL7gs_buf1+96>: 0 0 0 0

0x80495d0 <_ZL7gs_buf1+112>: 0 0 0 0

0x80495e0 <_ZL7gs_buf1+128>: 0 0 0 0

0x80495f0 <_ZL7gs_buf1+144>: 0 0 0 0

0x8049600 <_ZL7gs_buf1+160>: 0 0 0 0

0x8049610 <_ZL7gs_buf1+176>: 0 0 0 0

0x8049620 <_ZL7gs_buf1+192>: 0 0 0 0

0x8049630 <_ZL7gs_buf1+208>: 0 0 0 0

0x8049640 <_ZL7gs_buf1+224>: 0 0 0 0

0x8049650: 0 0 0 0

0x8049660 <_ZZ4mainE5base1>: 0 0 0 0

0x8049670 <_ZZ4mainE5base1+16>: 0 0 0 0

0x8049680 <_ZZ4mainE5base1+32>: 0 0 0 0

0x8049690 <_ZZ4mainE5base1+48>: 0 0 0 0

0x80496a0 <_ZZ4mainE5base1+64>: 0 0 0 0

0x80496b0 <_ZZ4mainE5base1+80>: 0 0 0 0

0x80496c0 <_ZZ4mainE5base1+96>: 0 0 0 0

0x80496d0: 0 0 0 0

0x80496e0 <_ZZ4mainE5temp1>: 0 0 0 0

0x80496f0 <_ZZ4mainE5temp1+16>: 0 0 0 0

0x8049700 <_ZZ4mainE5temp1+32>: 0 0 0 0

0x8049710: 0 0 0 0

0x8049720 <_ZZ4mainE4base>: 0 0 0 0

0x8049730 <_ZZ4mainE4base+16>: 0 0 0 0

0x8049740 <_ZZ4mainE4base+32>: 0 0 0 0

0x8049750 <_ZZ4mainE4base+48>: 0 0 0 0

0x8049760 <_ZZ4mainE4base+64>: 0 0 0 0

0x8049770 <_ZZ4mainE4base+80>: 0 0 0 0

0x8049780 <_ZZ4mainE4base+96>: 0 0 0 0

0x8049790: 0 0 0 0

0x80497a0 <_ZZ4funcvE2s1>: 0 0 0 0

0x80497b0 <_ZZ4funcvE2s1+16>: 0 0 0 0

0x80497c0 <_ZZ4funcvE2s1+32>: 0 0 0 0

0x80497d0: 0 0 0 0

0x80497e0: 0 0 0 0

0x80497f0: 0 0 0 0

0x8049800: 0 0 0 0

0x8049810: 0 0 0 0

0x8049820: 0 0 0 0

0x8049830: 0 0 0 0

0x8049840: 0 0 0 0

0x8049850: 0 0 0 0

分析�l�果�Q?/h3>
全局变量与静态变量的唯一区别在于链接属性，全局变量为外部链接属性，全局静态变量（�c�d��部的静态变量）为内部链接属性，函数内部的静态变量无链接属性�?
注：对于�c�d��部的静态变量，�c�d��相当于一个命名空��_��而全局静态变量的命名�I�间为：�Q�（全局命名�I�间�Q�，所以它们本质上无差�?
全局变量和静态变量内存布局基本相同�Q�这里一�q�考虑�?
全局/静态变量的内存分配主要是遵循一个大的原则，��初始化的和未初始化的变量分开存放�Q�初始化的变量被攑֜�全局数据区，未初始化的变量放在BSS�D�，�q�样有一个好处，BSS�D�在文�g中是没有大小的，只有一个地址�Q�所有未初始化的全局静态变量都指向�q�个地址�Q�这样可以减��文件的大小。而在�q�行�Ӟ��才会为BSS�D�分配内存空��_��q�且全部初始化�ؓ0�Q�所以未初始化的全局/静态变量蝲入内存后�Q�默认��gؓ0�?
然后我们看内存布局�Q?
前面4个变量依�ơ是�Q�g_buf3�Q�_ZZ4mainE1b�Q�_ZZ4mainE1a和_ZZ4funcvE2s2�Q�编译器在编译时��Z��防止名称冲突�Q�会对变量函数名�q�行名称修饰�Q�linux下可用c++filt工具�q�行�q�原�?
�q�原后的变量依次是：
g_buf3�Q�main函数中的静态变量b、a和func中的静态变量s2�?
�q?个是初始化了的全局/静态变量，所以被攑֜�全局初始化区�Q�这里我们得��Z��下几点结论�?
1、可以发现s2和s3都被初始化了�Q�可是只有s2被分配内存空��_��而s3�q�未分配内存�I�间�Q�这是因为linux中�ؓ静态变量分配内存是�Ҏ��该变量是否被使用来判断的�Q�如果一个静态变量定义后�Q�未发现它被其它变量引用了，��不会�ؓ其分配内存空间�?
2、对于全局变量�Q�不��它是否被��用了�Q�都会�ؓ其分配内存空间�?
3、在函数中的静态变量，在内存中的顺序恰恰和它们在函��C��的声明顺序相反（目前��不知这样做的原因）�?
�q�里有一个疑问，g_base和gs_base�q�两个变量被初始化了�Q��ؓ什么它们被攑֜�未初始化的全局数据区。这是因为g_base和gs_base�q�两个变量是在运行时通过调用构造函数被初始化的�Q�在�~�译时我们是无法知道它们的值的�Q�所以在�~�译时它们也被放在了BSS�D�c��所以这里得出结论：
4、全局/静态类变量在内存中被放在未初始化数据区�?
下面我们看看未初始化数据区里面的变量�Q�依�ơ是
g_buf1、g_buf2、g_base、gs_base、main函数的base1、temp1、base�Q�func函数的s1�?
可以看到g_base、gs_base��g��?�Q�而base1�Q�base的��gؓ0�Q�因为我的断�Ҏ��在main函数入口处设�|�的�Q�所以全局�c�d��量的构造函数已被调用过了，而main函数内的�c�d��量的构造函数尚未调用，但是它们的内存空间已被分配，�q�印证了以上�l�论4�?/p>

gifty 2011-05-07 15:52 发表评论

gifty — Mon, 02 May 2011 07:50:00 GMT

最�q�在弄GCC的预�~�译��_��用C++开发工�E�最难以忍受的就是乌龟似地的�~�译速度�Q�用VC开发工�E�的时候，VC会默认帮我们引入预编译头�Q�那么GCC呢？其实GCC也是支持预编译头得， http://lych.yo2.cn/articles/��谈gcc预编译头技�?html �q�篇文章��p��l�讲解了如何GCC下预�~�译头得一些知�? 所以具体如何在GCC中加入预�~�译�?大家可以参考这��文章�?

在给GCC��d��预编译头时也遇到了一些问题，�q�且对C++/C的编译有了一些新的认识！

很多在linux下写�E�序的�h都应该看�q�《和我一起写Makefile》这��文章，里面讲过如何利用GCC�?MM选项自动生成依赖�Q?/p>

%.d: %.cpp
@$(GPP) -MM $(INCLUDE) $< > $@.tmp;\
sed 's,$$*$\.o[ :]*,\1.o $@ : ,g' < $@.tmp > $@;\
rmf $@.tmp

�q�里利用了一个模式规则，��CPP文�g依赖的头文�g写到一�?d文�g中，执行Makefile时我们只需要include�q�些.d文�g�Q�GCC��׃��Ҏ��里面的依赖关�p�L��生成对应�?o文�g了！
但是实际上GCC的自动推��D��力非常强大，我们其实只需要写下一条这��L��模式��可以了�Q?
%.o:%.cpp
@$(GPP) $(CPPFLAGS) $< $(INCLUDE)

GCC��׃��自动推导出CPP文�g所需要依赖的头文件进行编译了�Q?/p>

如果你在自己的工�E�中加入了预�~�译��_��你就必须使用下面一�U�模式�?
举个例子�Q�比如你们工�E�开发了一些基��库，已经比较�E�_��了，除了一些少量的BUG FIX外，很少需要修改，当你通过源码形式引用的时候，你当然不希望每次�~�译的时候都�ȝ��?
�q�些基础库，如是你决定将他们加入预编译头中去�Q�但是当你��用第一�U�方式写Makefile的时候，你发现被你加入到预编译头中的头文件还是被重复�~�译了，因�ؓ-MM选项会把你CPP文�g
依赖的非�pȝ��头文件全部放在对应的.d文�g中。但是当你��用第二种Makefile�Ӟ��GCC看到一个预�~�译头后�Q�他不会按照常规的方式将它展开�Q�而是回去��L��对应�?gch文�g�Q�然后进行编译，
如果你想一探究竟的�?�~�译加上-H选项��可以看出其中的差异了！

�q�样生成的预�~�译头如果要使用的话�Q�需要和�~�译CPP文�g使用相同的选项�Q�否则后出现一些奇怪的�~�译错误�Q�我的做法是写一个预�~�译头得模式�Q?/p>
%.h.gch:%.h
$(GPP) $(CPPFLAGS) $< $(INCLUDE)

gifty 2011-05-02 15:50 发表评论

午夜欧美精品,国产精品无人区,国产一区二区三区黄

全局/静态变量内存布局

内存布局