利用MFC向?qū)Ы⒁粋€(gè)工程，然后開始編碼。這就是我通常做一個(gè)MFC工程的開始。但向?qū)Э刹皇且粋€(gè)守規(guī)矩的東西，它會(huì)為你添加很多的代碼，為你設(shè)置大量的編譯和鏈接選項(xiàng)。大部分時(shí)候這種工作是善意的，但是好心不一定辦好事，你不好好了解它，它會(huì)給你帶來(lái)很多的麻煩。

在配置一個(gè)基于OpenCasCade的程序中，我就遇到了很多麻煩。MFC向?qū)г谒傻腣iew, Document等架構(gòu)類中都添加了一段如下代碼：

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

在Debug狀態(tài)下（VS會(huì)為你默認(rèn)添加一個(gè)_DEBUG的預(yù)編譯項(xiàng)），你在該類中調(diào)用的new操作符都會(huì)被DEBUG_NEW所取代，請(qǐng)警惕這個(gè)行為，如果你重載過某個(gè)類的new，很可能就會(huì)由于它導(dǎo)致無(wú)法編譯通過或運(yùn)行不正確。

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

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

也許你看上面的錯(cuò)誤都很簡(jiǎn)單，但如果不小心，也許有天也會(huì)像我一樣深陷其中半天爬不出來(lái)。總之，在天天用VS2005建MFC工程的時(shí)候，提前做好兩件事。一件是通讀一遍系統(tǒng)默認(rèn)生成的代碼，做到心中有數(shù)，每一條莫名其妙的東西都要了解一下它的用途；另一件是在剛開始和改變了工程屬性之后查看一下你的編譯和鏈接命令，搞清楚它做了什么事，有時(shí)候命令行雖然難記一點(diǎn)，但確實(shí)是一目了然，你可以不必每天用命令行編譯程序，但一定要對(duì)這些命令心如明鏡，了如指掌才好。