① 有关C++的问题~~请教
1、就是在dlg2.h的文件中为何非得加上class CDlg1;？？
当然需要，在dlg2中也要加上对dlg1的引用，用class CDlg1是为避免循环重复引用。
2、道理同上。
看下面的详细解释：
一、类嵌套的疑问
C++头文件重复包含实在是一个令人头痛的问题，前一段时间在做一个简单的数据结构演示程序的时候，不只一次的遇到这种问题。假设我们有两个类A和B，分别定义在各自的有文件A.h和B.h中，但是在A中要用到B，B中也要用到A，但是这样的写法当然是错误的：
class B;
class A
{
public:
B b;
};
class B
{
public:
A a;
};
因为在A对象中要开辟一块属于B的空间，而B中又有A的空间，是一个逻辑错误，无法实现的。在这里我们只需要把其中的一个A类中的B类型成员改成指针形式就可以避免这个无限延伸的怪圈了。为什么要更改A而不是B？因为就算你在B中做了类似的动作，也仍然会编译错误，表面上这仅仅上一个先后顺序的问题。
为什么会这样呢？因为C++编译器自上而下编译源文件的时候，对每一个数据的定义，总是需要知道定义的数据的类型的大小。在预先声明语句class B;之后，编译器已经知道B是一个类，但是其中的数据却是未知的，因此B类型的大小也不知道。这样就造成了编译失败，VC++6.0下会得到如下编译错误：
error C2079: ‘b’ uses undefined class ‘B’
将A中的b更改为B指针类型之后，由于在特定的平台上，指针所占的空间是一定的（在Win32平台上是4字节），这样可以通过编译。
二、不同头文件中的类的嵌套
在实际编程中，不同的类一般是放在不同的相互独立的头文件中的，这样两个类在相互引用时又会有不一样的问题。重复编译是问题出现的根本原因。为了保证头文件仅被编译一次，在C++中常用的办法是使用条件编译命令。在头文件中我们常常会看到以下语句段（以VC++6.0自动生成的头文件为例）：
#if !defined(AFX_STACK_H__1F725F28_AF9E_4BEB_8560_67813900AE6B__INCLUDED_)
#define AFX_STACK_H__1F725F28_AF9E_4BEB_8560_67813900AE6B__INCLUDED_
//很多语句……
#endif
其中首句#if !defined也经常做#ifndef，作用相同。意思是如果没有定义过这个宏，那么就定义它，然后执行直到#endif的所有语句。如果下次在与要这段代码，由于已经定义了那个宏，因此重复的代码不会被再次执行。这实在是一个巧妙而高效的办法。在高版本的VC++上，还可以使用这个命令来代替以上的所有：
#pragma once
它的意思是，本文件内的代码只被使用一次。
但是不要以为使用了这种机制就全部搞定了，比如在以下的代码中：
//文件A.h中的代码
#pragma once
#include “B.h”
class A
{
public:
B* b;
};
//文件B.h中的代码
#pragma once
#include “A.h”
class B
{
public:
A* a;
};
这里两者都使用了指针成员，因此嵌套本身不会有什么问题，在主函数前面使用#include “A.h”之后，主要编译错误如下：
error C2501: ‘A’ : missing storage-class or type specifiers
仍然是类型不能找到的错误。其实这里仍然需要前置声明。分别添加前置声明之后，可以成功编译了。代码形式如下：
//文件A.h中的代码
#pragma once
#include “B.h”
class B;
class A
{
public:
B* b;
};
//文件B.h中的代码
#pragma once
#include “A.h”
class B;
class B
{
public:
A* a;
};
这样至少可以说明，头文件包含代替不了前置声明。有的时候只能依靠前置声明来解决问题。我们还要思考一下，有了前置声明的时候头文件包含还是必要的吗？我们尝试去掉A.h和B.h中的#include行，发现没有出现新的错误。那么究竟什么时候需要前置声明，什么时候需要头文件包含呢？
三、两点原则
头文件包含其实是一想很烦琐的工作，不但我们看着累，编译器编译的时候也很累，再加上头文件中常常出现的宏定义。感觉各种宏定义的展开是非常耗时间的，远不如自定义函数来得速度。我仅就不同头文件、源文件间的句则结构问题提出两点原则，仅供参考：
第一个原则应该是，如果可以不包含头文件，那就不要包含了。这时候前置声明可以解决问题。如果使用的仅仅是一个类的指针，没有使用这个类的具体对象（非指针），也没有访问到类的具体成员，那么前置声明就可以了。因为指针这一数据类型的大小是特定的，编译器可以获知。
第二个原则应该是，尽量在CPP文件中包含头文件，而非在头文件中。假设类A的一个成员是是一个指向类B的指针，在类A的头文件中使用了类B的前置声明并便宜成功，那么在A的实现中我们需要访问B的具体成员，因此需要包含头文件，那么我们应该在类A的实现部分（CPP文件）包含类B的头文件而非声明部分(H文件)。
② 一个C++工程中，许多个文件都include某一个类，当该类更新时，编译速度太慢，怎么办
这是个好问题，虽然老生常谈，但真正知道解决方案的人很少。《EffectiveC++》有介绍，同时推荐这本书给所有C++er。
一个组织有问题的大型项目中，影响编译速度的最大问题就是头文件形成庞大的依赖网络，其中一个头文件修改就导致一大堆间接依赖的源代码文件需要重新编译。a.h包含b.h，b.h包含c.h，c.h又包含d.h，即使a.h和d.h似乎没什么关系，修改d.h的时候还是无可避免a.cc被重新编译。
首先得知道C++一个特性，函数分为声明和实现两部分是人所皆知，但类也可以分为前置声明和定义可能知道的人就比较少了，知道能怎么用就更少了，其实就是可以用来解决编译速度问题的。
③ C++前置声明的问题
函数声明只是一个符号声明，调用的地方只需要知道他的参数是什么样的，返回什么样的值就可以了。调用的地方不需要知道其中的细节，所是没有问题。另外函数名是一个地址，函数调用是一个地址跳转而已，只需使用一个指针的内存。
而类对象就不一样了，编译期间必须要确定类所占的空间。像上面的类A无法确定类B的大小，所以编译失败。如果是循环引用这种是必须用类指针，即：
classB;
classA{
B*b;
};
classB{
Aa;//或A*a;
}
“读到函数的前置声明的时候，会跳转到函数定义的地方进行编译么？ ”
答：不会，只是保存一个函数指针。
“读到类的前置声明的时候，会跳转到类定义的地方进行编译么？”
答：不会，也仅仅是一个符号声明
④ 浅谈怎样加快C++代码的编译速度
首先一点 加快编译速度意义不大。
需要整个项目重新编译的情况并不多，而每次只修改若干文件的情况下，加快速度也不会有太大影响。
更重要的应该把目光放在加快运行速度上。
要加快编译速度，可以从这几个方面尝试。
一、代码角度
1、在头文件中使用前置声明，而不是直接包含头文件。
不要以为你只是多加了一个头文件，由于头文件的"被包含"特性，这种效果可能会被无限放大。所以，要尽一切可能使头文件精简。很多时候前置申明某个namespace中的类会比较痛苦，而直接include会方便很多，千万要抵制住这种诱惑；类的成员，函数参数等也尽量用引用，指针，为前置声明创造条件。
2、使用Pimpl模式
Pimpl全称为Private Implementation。传统的C++的类的接口与实现是混淆在一起的，而Pimpl这种做法使得类的接口与实现得以完全分离。如此，只要类的公共接口保持不变，对类实现的修改始终只需编译该cpp；同时，该类提供给外界的头文件也会精简许多。
3、高度模块化
模块化就是低耦合，就是尽可能的减少相互依赖。这里其实有两个层面的意思。一是文件与文件之间，一个头文件的变化，尽量不要引起其他文件的重新编译；二是工程与工程之间，对一个工程的修改，尽量不要引起太多其他工程的编译。这就要求头文件，或者工程的内容一定要单一，不要什么东西都往里面塞，从而引起不必要的依赖。这也可以说是内聚性吧。
以头文件为例，不要把两个不相关的类，或者没什么联系的宏定义放到一个头文件里。内容要尽量单一，从而不会使包含他们的文件包含了不需要的内容。记得我们曾经做过这么一个事，把代码中最"hot"的那些头文件找出来，然后分成多个独立的小文件，效果相当可观。
其实我们去年做过的refactoring，把众多DLL分离成UI与Core两个部分，也是有着相同的效果的 - 提高开发效率。
4、删除冗余的头文件
一些代码经过上十年的开发与维护，经手的人无数，很有可能出现包含了没用的头文件，或重复包含的现象，去掉这些冗余的include是相当必要的。当然，这主要是针对cpp的，因为对于一个头文件，其中的某个include是否冗余很难界定，得看是否在最终的编译单元中用到了，而这样又可能出现在一个编译单元用到了，而在另外一个编译单元中没用到的情况。
之前曾写过一个Perl脚本用来自动去除这些冗余的头文件，在某个工程中竟然去掉多达了5000多个的include。
5、特别注意inline和template
这是C++中两种比较"先进"的机制，但是它们却又强制我们在头文件中包含实现，这对增加头文件的内容，从而减慢编译速度有着很大的贡献。使用之前，权衡一下。
二、综合技巧
1、预编译头文件（PCH）
把一些常用但不常改动的头文件放在预编译头文件中。这样，至少在单个工程中你不需要在每个编译单元里一遍又一遍的load与解析同一个头文件了。
2、Unity Build
Unity Build做法很简单，把所有的cpp包含到一个cpp中(all.cpp) ,然后只编译all.cpp。这样我们就只有一个编译单元，这意味着不需要重复load与解析同一个头文件了，同时因为只产生一个obj文件，在链接的时候也不需要那么密集的磁盘操作了,估计能有10x的提高，看看这个视频感受一下其做法与速度吧。
3、ccache
compiler cache, 通过cache上一次编译的结果，使rebuild在保持结果相同的情况下，极大的提高速度。我们知道如果是build，系统会对比源代码与目标代码的时间来决定是否要重新编译某个文件，这个方法其实并不完全可靠(比如从svn上拿了上个版本的代码)，而ccache判断的原则则是文件的内容，相对来讲要可靠的多。
很可惜的是，Visual Studio现在还不支持这个功能 - 其实完全可以加一个新的命令，比如cache build，介于build与rebuild之间，这样，rebuild就可以基本不用了。
4、不要有太多的Additional Include Directories
编译器定位你include的头文件，是根据你提供的include directories进行搜索的。可以想象，如果你提供了100个包含目录，而某个头文件是在第100个目录下，定位它的过程是非常痛苦的。组织好你的包含目录，并尽量保持简洁。
三、编译资源
要提高速度，要么减少任务，要么加派人手，前面两个方面讲得都是减少任务，而事实上，在提高编译速度这块，加派人手还是有着非常重要的作用的。
1、并行编译
买个4核的，或者8核的cpu，每次一build，就是8个文件并行着编，那速度，看着都爽。 要是你们老板不同意，让他读读这篇文章：Hardware is Cheap, Programmers are Expensive
2、更好的磁盘
我们知道，编译速度慢很大一部分原因是磁盘操作，那么除了尽可能的减少磁盘操作，我们还可以做的就是加快磁盘速度。比如上面8个核一块工作的时候，磁盘极有可能成为最大的瓶颈。买个15000转的磁盘，或者SSD，或者RAID0的，总之，越快越好。
3、分布式编译
一台机子的性能始终是有限的，利用网络中空闲的cpu资源，以及专门用来编译的build server来帮助你编译才能从根本上解决我们编译速度的问题，想想原来要build 1个多小时工程的在2分钟内就能搞定，你就知道你一定不能没有它 - Incredibuild。
4、并行，其实还可以这么做。
这是一个比较极端的情况，如果你用了Incredibuild，对最终的编译速度还是不满意，怎么办？其实只要跳出思维的框架，编译速度还是可以有质的飞跃的 - 前提是你有足够多的机器：
假设你有solution A和solution B，B依赖于A，所以必须在A之后Build B。其中A，B Build各需要1个小时，那么总共要2个小时。可是B一定要在A之后build吗？跳出这个思维框架，你就有了下述方案：
◦同时开始build A和B 。
◦A的build成功，这里虽然B的build失败了，但都只是失败在最后的link上。
◦重新link B中的project。
⑤ c++builder编译速度太慢，能不能通过设置来加快
C＋＋builder是最快的C＋＋编译器之一，从编译速度来说也可以说是最快的win32C＋＋编译器了。除了速度之外，C++builder的性能也在其它C＋＋编译器的之上，但许多delphi程序员仍受不了c++builder工程的编译速度。的确，delphi的速度要比任和c++的编译器都要快好多。Delphi在编译一个小工程的时候可能不到一秒，大的工程一般也在5秒钟这内编译完成了。
为什么delphi会比c++builder快这么多？是否有方法来c++builder的编译速度？本文就讲解了为什么C＋＋的编译器速度会慢，并且介绍了一个简单的方法来减少c++builder的编译时间。
为什么c++编译器的速度会慢？
c++builder 使用者怎么通过预编译头文件来减少编译时间？
讲解基于VCL可视化工程的预编译头文件方法
优化c++builder对预编译头文件的使用
结论
注意事项
为什么c++编译器速度慢？
在C＋＋中，你只能使用预定义或是预先声明了的函数，这意味什么？来看一个简单的例子，函数A()调用函数B（），函数A（）只能在函数B（）的原型或是函数体在A（）之前才能调用它
⑥ C++类的前置声明问题
因为编码器在读到X obj;时还不知道X的大小，无法为class Y分配内存空间。
如果把声明顺序反一下就可以通过了。
class Y;
class X{
private: Y* ptr; //这里虽然Y还没有声明，但编码器知道这是一个指针，至于指向什么数据可以先不关心。
};
class Y{
X obj;
};
int main()
{
Y y;
return 0;
}