① 有關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;
}