利用MFC向導建立一個工程，然后開始編碼。這就是我通常做一個MFC工程的開始。但向導可不是一個守規矩的東西，它會為你添加很多的代碼，為你設置大量的編譯和鏈接選項。大部分時候這種工作是善意的，但是好心不一定辦好事，你不好好了解它，它會給你帶來很多的麻煩。

在配置一個基于OpenCasCade的程序中，我就遇到了很多麻煩。MFC向導在它所生成的View, Document等架構類中都添加了一段如下代碼：

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

在Debug狀態下（VS會為你默認添加一個_DEBUG的預編譯項），你在該類中調用的new操作符都會被DEBUG_NEW所取代，請警惕這個行為，如果你重載過某個類的new，很可能就會由于它導致無法編譯通過或運行不正確。

除此之外一些默認的設置也要注意，在VS2005中是默認支持Unicode的，它會在你的編譯選項中加入/D "_UNICODE" /D "UNICODE"。這就會使得CString和你可能用到的std::string存在很麻煩的轉換問題。你需要修改項目屬性中General-->Character Set為not set，將其設為ununicode，保證與std::string的一致（當然你還可以運用其他的解決方法滿足你的需求）。

有時候IDE也會“好心辦壞事”，比如在一個解決方案中有兩個工程，你為A添加B的編譯依賴，在A的鏈接選項中就會悄悄加上對B生成的dll的引用。當你某天整理代碼取消了這個依賴的時候，你突然發現莫名的出現了很多link錯誤。不要慌張，在A中添加上B鏈接項就好了，這項工作其實是你必須自己做的，只是你添加了依賴編譯器非常主動的幫你完成了。

也許你看上面的錯誤都很簡單，但如果不小心，也許有天也會像我一樣深陷其中半天爬不出來?？傊谔焯煊肰S2005建MFC工程的時候，提前做好兩件事。一件是通讀一遍系統默認生成的代碼，做到心中有數，每一條莫名其妙的東西都要了解一下它的用途；另一件是在剛開始和改變了工程屬性之后查看一下你的編譯和鏈接命令，搞清楚它做了什么事，有時候命令行雖然難記一點，但確實是一目了然，你可以不必每天用命令行編譯程序，但一定要對這些命令心如明鏡，了如指掌才好。