利用MFC向?qū)Ы⒁粋€(gè)工程，然后開(kāi)始編碼。這就是我通常做一個(gè)MFC工程的開(kāi)始。但向?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è)行為，如果你重載過(guò)某個(gè)類的new，很可能就會(huì)由于它導(dǎo)致無(wú)法編譯通過(guò)或運(yùn)行不正確。

除此之外一些默認(rèn)的設(shè)置也要注意，在VS2005中是默認(rèn)支持Unicode的，它會(huì)在你的編譯選項(xiàng)中加入/D "_UNICODE" /D "UNICODE"。這就會(huì)使得CString和你可能用到的std::string存在很麻煩的轉(zhuǎn)換問(wè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ù)，每一條莫名其妙的東西都要了解一下它的用途；另一件是在剛開(kāi)始和改變了工程屬性之后查看一下你的編譯和鏈接命令，搞清楚它做了什么事，有時(shí)候命令行雖然難記一點(diǎn)，但確實(shí)是一目了然，你可以不必每天用命令行編譯程序，但一定要對(duì)這些命令心如明鏡，了如指掌才好。