程序的静态数据量大的时候，有时候会出现栈溢出问题，往往是程序还没运行算法呢，就down掉了， 比如你在创建包含大数组的类（或数据）的时候，栈就溢出了。这是由于系统分配给程序的栈空间太小。

一种方法，就是不要静态分配，用new动态创建，是从堆中分配的，堆的空间足够大，不过记得写析构 函数，delete你申请的堆空间。其实这样也挺方便，类结束的时候会自动调用析构函数释放空间。养成”不在栈上定义大数组/大对象”的好习惯很重要，否 则再大的栈也会被撑爆的。

当然，如果你不喜欢new，delete的话，还是静态 分配（毕竟静态分配有很多好处），那么可以通过改变默认栈空间来解决。

LINK的/STACK选项

/STACK   :reserve[,commit]

reserve:栈总大小

commit:程序开始时系统提供的实际内存量

缺省：1M,8K

参数为0取缺省值

今天在VC++.NET 中运行聚类程序，老是说Stack   OverFlow,  后来才发现是栈空间太小了。

单单保存100个网页的数据量就比较大了。

把堆栈的大小已经设置 为:

堆栈保留大小为：100000000；

堆栈提交大小为:   100000000;

就没问题了。

设置：项目-> 属性-> 链接器-> system-> 堆栈保留大小/堆栈提交大小

问题解答：

方 法一：STACKSIZE   定义.def文件

语法：STACKSIZE reserve[,commit]
reserve：栈的大小；commit：可选项，与操作系统有关，在NT上只一次分配物理内存的大小

方法二：设定/STACK

打开工程，依次操作菜单如下：Project->Setting->Link，在Category 中选中Output，然后
在 Reserve中设定堆栈的最大值和commit。

注意：reserve默认值为1MB,最小值为4Byte；commit是保留在虚拟 内存的页文件里面，它设置的较
大会使栈开辟较大的值，可能增加内存的开销和启动时间

您可能还对这些文章感兴趣

• 七月 14, 2009 -- vc++6.0中view消失的BUG (0)
• 五月 1, 2009 -- c++中的指针 (0)
• 五月 1, 2009 -- VC++是如何编译的 (0)
• 六月 18, 2010 -- WordPress 3.0 正式版发布 (0)
• 六月 11, 2010 -- 快速转移国际域名的方法 (24)
• 四月 18, 2010 -- 从进程中判断出病毒和木马 (0)
• 四月 17, 2010 -- 本站域名今日更换解析服务器 (0)
• 四月 3, 2010 -- 本站论文板块即将开启，尽请期待！ (0)
• 四月 2, 2010 -- 你会用shutdown吗？看看吧 (0)
• 三月 20, 2010 -- 网站链接优化 (0)

在我们执行某些操作的时候（例如在上面点击右键—“”add member function”或者“add windows message handler”时），这个类可能就不见了（有一定的概率）

这个时候我们该怎么办呢？

很简单

只要切换到fileview 然后在双击相应的XXXVIEW.h，打开这个头文件，在头文件的前部随便打上几个空格，然后再切换到class view，这时候，CXXXview就又出现了

您可能还对这些文章感兴趣

• 四月 2, 2010 -- 设置c++程序的堆栈空间解决栈溢出问题 (0)
• 三月 20, 2010 -- 告诉你C盘里的每个文件夹都是干嘛的，哪个可以删除，哪些不能碰呢 (0)
• 二月 28, 2010 -- 免费数据恢复软件：NTFSUndelete (0)
• 二月 28, 2010 -- WinXP中CPU占用率100%原因及解决方法 (0)
• 二月 28, 2010 -- 一条命令解决解决该内存不能为“read”或“written” (0)
• 二月 28, 2010 -- 我印象中的Internet Explorer浏览器 (0)
• 十一月 11, 2009 -- 轻松安装系统驱动 (0)
• 七月 25, 2009 -- 卡巴斯基2010key的添加方法 （命令行） (0)
• 七月 23, 2009 -- 卡巴斯基2010简体中文版上市 (0)
• 七月 13, 2009 -- 加密文件或文件夹 (0)

合理的使用指针可以使你的程序更加高效，而且程序中的很多操作都必须使用指针来完成。

您可能还对这些文章感兴趣

• 四月 2, 2010 -- 设置c++程序的堆栈空间解决栈溢出问题 (0)
• 七月 14, 2009 -- vc++6.0中view消失的BUG (0)
• 五月 1, 2009 -- VC++是如何编译的 (0)
• 四月 30, 2009 -- 给C++初学者的50个忠告 (0)

下面就是对vc++内部机制的简单介绍。

Jan Gray在1994曾经写了一篇叫做C++ under the Hood的文章，介绍了Visual C++的实现细节。这篇指南就是基于Jan的文章之上，我同时会将Jan文章中让人难于理解的地方详细阐述。希望这篇指南可以让更多的人了解C++的底层 实现机制。

The layout of a Class

struct B {
public:
int bm1;
protected:
int bm2;
private:
int bm3;
};
Struct B 在内存中的layout是怎么样的？ Visual C++保证B中的member variables 在内存中的layout与它们生命的顺序一致。Struct B在内存的中layout应该是这个样子的：

Single Inheritance
struct C {
int c1;
void cf();
};
struct D : C {
int d1;
void df();
};
在Visual C++中保证在C的member variables 在内存中的位置永远在D的起始位置。就像这样:

这样做的好处是当C* pC = new D();Visual C++不需要为pC做额外的displacement 转换。pC 的address equal D* pD = new D();中的pD.

Multiple Inheritance
比较复杂：
struct E {
int e1;
void ef();
};
struct F : C, E {
int f1;
void ff();
};
多重继承比较复杂，他们的Base和Derived的指针的位置不再相同。
F f;
// (void*)&f == (void*)(C*)&f;
// (void*)&f < (void*)(E*)&f;
通过如下的Diagram of layout你可以看得更加清楚：

为什么在图中C在E的上面？这是Visual C++ 的convention罢了，基类在内存中的layout correspond to 他们的的声明顺序。因为C的声明在E的前面，所以我们看到的F在内存的layout就是这样子的。
由 此图可知，E *pE = new F() 与C *pC = new F()中的pE 和pC指向的内存位置并不相同，对于pC 来说compiler不需要额外做任何事情，但是对于pE，为了让它指向E在内存中的位置compiler需要进行一种叫做displacement的调 整。

Virtual Inheritance
请考虑这种情形：
struct Employee { … };
struct Manager : Employee { … };
struct Worker : Employee { … };
struct MiddleManager : Manager, Worker { … };

无疑，按照我们之前的叙述，MiddleManager在内存中的layout应该是这个样的:

在内存中的有两个Employee的实例，如何Employee 很小那么这种冗余是可以忽略的，可是如果Employee很大呢？ 那么有没有什么方法可以让Manager 和Worker在内存中共享同一个Instance呢？这就是Virtual Inheritance需要解决的问题。
在享受这种优化的服务之前，你应该将你的类体系结构编程这样：
struct Employee { … };
struct Manager : virtual Employee { … };
struct Worker : virtual Employee { … };
struct MiddleManager : Manager, Worker { … };

也就是在希望被sharing 的基类前面加上Virtual关键字，多么直观啊。
struct G : virtual C {
int g1;
void gf();
};
struct H : virtual C {
int h1;
void hf();
};
struct I : G, H {
int i1;
void _if();
};

之后你的类在内存中的就应该是这个样子：

其中vbptr中存储的是对Employee的相对displacement.
Data Member Access
在没有继承的情形：
C* pc;
pc->c1; // *(pc + dCc1);

c1 的访问类似于*(pC + displacement of c1 within C);在本例子中根据Class C的定义和Diagram of layout我们可以发现displacement == 0.
在单继承的情形中：
D* pd;
pd->c1; // *(pd + dDC + dCc1); // *(pd + dDCc1);
pd->d1; // *(pd + dDd1);

根据我们之前的Diagram不难看出pd->c1 == *(pd + displacement from D to C + displacement from C to c1).这种情形中displacement == 0。
pd->d1 == *(pd + displacement from D to d1). 这种情形中 displacement == 4。
在多重继承中，情形稍微复杂些，但所有的displacement 还都是常量(constant)。
F* pf;
pf->c1; // *(pf + dFC + dCc1); // *(pf + dFc1);
pf->e1; // *(pf + dFE + dEe1); // *(pf + dFe1);
pf->f1; // *(pf + dFf1);
我想何以根据我们之前的Diagram轻松的算出每一个displacement。
虚拟继承又是怎么的呢？
I* pi;
pi->c1; // *(pi + dIGvbptr + (*(pi+dIGvbptr))[1] + dCc1);
pi->g1; // *(pi + dIG + dGg1); // *(pi + dIg1);
pi->h1; // *(pi + dIH + dHh1); // *(pi + dIh1);
pi->i1; // *(pi + dIi1);
I i;
i.c1; // *(&i + IdIC + dCc1); // *(&i + IdIc1);

对g1,h1,以及i1的访问很容易理解，我想说说对c1的访问。
pi->c1 是一种动态的访问。在runtime的时候编译器不知道pi的真正type是什么，这时就要用到之前说过的vbptr，(*(pi + dIGvbptr))[1]是指在特定的vbptr中(不论vbptr是属于 G还是H)其对于base virtual class的偏移地址。至于为什么是(*(pi + dIGvbptr))[1] 而不是 (*(pi + dIGvbptr))[0]，我猜这也是Visual C++的设计使然吧。 如果你知道(*(pi + dIGvbptr))[0]中放的什么，请让我知道
对于i.c1的访问，因为这是一种静态的访问，为了节省开销C++对它的处理直接而干脆。之所以C++敢于这么做是因为在I中displacement of i在这种静态声明中是固定不变的。

Casts
理解了以上概念相信Casts between 2 types就不是什么问题了，一下是我们常见的一些cast在Visual C++中的实现手段。
对于多重继承来说：
F* pf;
(C*)pf; // (C*)(pf ? pf + dFC : 0); // (C*)pf;
(E*)pf; // (E*)(pf ? pf + dFE : 0);
对于虚拟继承来说：
I* pi;
(G*)pi; // (G*)pi;
(H*)pi; // (H*)(pi ? pi + dIH : 0);
(C*)pi; // (C*)(pi ? (pi+dIGvbptr + (*(pi+dIGvbptr))[1]) : 0);

什么，没看懂？那么就再看一遍我对Data Member Access的描述吧。
Member Functions
struct P {
int p1;
void pf(); // new
virtual void pvf(); // new
};
对于一个non-static 成员变量的访问应该是这样的(我想因该大部分程序员都会了解吧)member function被调用的的时候会被传入一个this指针他的类型是:
Type X * co
nst。(有人想过为什么是会是这样的声明而不是const Type X * const 或者const Type X *么？
如 果声明为const Type X *那么我们将无法通过this指针修改member variables。至于const Type X * const么实际上当你 将pf定义成：void pf() const;那么传入的this就是const Type X * const的。通过Type X * const 我们不能擅自修改this指针本身，不信你试试。)
所以对于pf的调用实际上应该是这个样子的：
void P::pf() { // void P::pf([P *const this])
++p1;   // ++(this->p1);
}

Overriding Member Functions
考虑以下声明：
struct Q : P {
int q1;
void pf(); // overrides P::pf
void qf(); // new
void pvf(); // overrides P::pvf
virtual void qvf(); // new
};
Overridden member function包括 static 和 dynamic 调用。在C++中使用virtual关键字来区分。
情形1：static resolution:
当一个member function被重写且没有virtual那么，对他的调用在compiling 的时候就已经determined.
P p; P* pp = &p; Q q; P* ppq = &q; Q* pq = &q;
pp->pf(); // pp->P::pf(); // P::pf(pp);
ppq->pf(); // ppq->P::pf(); // P::pf(ppq);
pq->pf(); // pq->Q::pf(); // Q::pf((P*)pq);
pq->qf(); // pq->Q::qf(); // Q::qf(pq);

当pp->pf() 以及 ppq->pf()这两种情形，调用它们的指针类型在compiling是就已经安插。因为没有Virtual 那么就没有多态的干扰，Visual C++将忠实于->运算符左侧的类型，并且将此类型作为this传入此函数。

情形 2：dynamic resolution：
pp->pvf(); // pp->P::pvf(); // P::pvf(pp);
ppq->pvf(); // ppq->Q::pvf(); // Q::pvf((Q*)ppq);
pq->pvf(); // pq->Q::pvf(); // Q::pvf((P*)pq);

可怜的C++编译器，将如何决议overridden member function 的类型呢？为了解决这个问题vfptr被引入。
通常被安插在memory layout的第一个位置，它指向此class的 vftable。 Vftable中存储的是所有virtual functions的地址。就像这样：

当子类重写了父类的方法那么vftable中相应的entry 就应该被改写，如图：

C++就是通过这种方式来进行overridden member function 的dynamic resolution。

Virtual Functions: Multiple Inheritance
这是本指南最刺激和有趣的一部分，我要向你介绍著名的Thunk技术。
考虑一下情形：
struct R {
int r1;
virtual void pvf(); // new
virtual void rvf(); // new
}；
struct S : P, R {
int s1;
void pvf(); // overrides P::pvf and R::pvf
void rvf(); // overrides R::rvf
void svf(); // new
};

这样的layout应该如何画？我猜是这样的：

S s; S* ps = &s;
((P*)ps)->pvf(); // ((P*)ps)->P::vfptr[0])((S*)(P*)ps)
((R*)ps)->pvf(); // ((R*)ps)->R::vfptr[0])((S*)(R*)ps)
当 我lunching以上两种调用，我所期望的的函数语义应该是就像每个函数注释后面的一样。毕竟->运算符左侧的是一个S*对吧，所以传入 member function的指针也应该是S*。当使用P*是问题很简单，P*和S*指向的是相同的内存地址，C++ compiler不需要做任何事情。但是当使用R*后有点问题，R*和S*指向的内存地址不同。那么我们就要使用一些技巧让R*指针转化为S*。对于这个 问题的解决办法基本上就是使用一种叫做Thunk的技术。重写 entry of pvf within vftable。
重写的方法很多，在VC++中重写后的结果像这样：

S::pvf-adjust: // MSC++
this -= SdPR;
goto S::pvf()
呵呵，很简单是么，将原先指向R*的this指针- displacement of S from R, 然后jump 到真正的S::pvf()的函数地址中。

Constructors and Destructors
Constructor 和 Destructor我们常见，但是不能使用。通常有compiler将其分解成为多部构造。
Constructor 被分解后应该是这样的：
1)对于一个most derived类，初始化vbptr，并调用virtual base 的构造函数。
2)调用non-virtual base classes 的构造函数。
3)调用data members的构造函数
4)初始化vfptr。
5)执行用户写在constructor中的代码。
Destructor被分解后应该是这样的：
1） 初始化vfptr
2） 执行用户卸载destructor中的代码。
3） 调用data member 的析构函数，顺序是与data member 在类中声明的顺序相反。
4） 调用non-virtual bases的析构函数，与声明的顺序相反。
5） 对于一个most derived 的类，调用它的virtual base的析构函数。

您可能还对这些文章感兴趣

• 四月 2, 2010 -- 设置c++程序的堆栈空间解决栈溢出问题 (0)
• 七月 14, 2009 -- vc++6.0中view消失的BUG (0)
• 五月 1, 2009 -- c++中的指针 (0)
• 四月 30, 2009 -- 给C++初学者的50个忠告 (0)

您可能还对这些文章感兴趣

• 四月 2, 2010 -- 设置c++程序的堆栈空间解决栈溢出问题 (0)
• 七月 14, 2009 -- vc++6.0中view消失的BUG (0)
• 五月 1, 2009 -- c++中的指针 (0)
• 五月 1, 2009 -- VC++是如何编译的 (0)