工作關係，接觸Windows下基於MFC的DLL（dynamic link library）的開發比較多一些，用過VS2002的開發環境，也用過VS2010的開發環境，對於C／C++開發而言，VS2002用的是VC7.0 IDE，VS2010用的是VC10.0 IDE. 兩個編譯環境同時在工作中使用，就免不了有一些移植程式碼的工作，不同VC版本程式碼之間的移植網上百度一下，應該比較好找到，有幾點想總結一下：

• CString ，string， char ＊之間的轉換：

              新建一個VS2010的基於MFC的DLL的工程，預設的編碼方式就是Multi-Byte，與之對應的還有unicode編碼方式，舉個例子簡單區別一下，在Multi-Byte下定義一個CString szContent = _T("1234"); 對於字元‘1’，‘2’，‘3’，‘4’而言，它們各佔一個byte的記憶體空間，而同樣的定義，在unicode編碼方式下佔兩個byte的記憶體空間。那麼自然而然的，CString 轉 string 或者char ＊就分兩種情況了，一種是CString 在 Multi-Byte 編碼下定義，另一種就是CString 在 unicode 下定義，這兩種編碼方式下的轉換方式是完全不同的，至於為什麼會出現這兩種編碼方式，之前百度過，就不多說了，有興趣的話自己百度一下就OK了！在專案開發過程中一般用Multi-Byte就可以了，遇到CString， string和 char ＊的轉換就會簡單很多，之前用了unicode編碼，我的轉換過程是這樣的，CString->std::w_string->std::string,   CString->w_char *-> char *,網上有很多方法啦，大多基於Win32 API 搞定的，也有大神自己寫程式碼轉換的，但是網上大多沒有提出基於哪一中編碼方式，所以用的時候要先搞清楚。

• Win32 API 和標準C／C++庫：

         既然是Library的開發，那肯定是要提供header file, 我在做第一個專案的時候遇到這樣一個問題，我開發的是Library，在給機器軟體組提供的header file中用了一個 CString型別的變數作為函式的入參，我自己當時倒是沒覺得有什麼不對的，可是機器軟體組的同事用的是C#寫的介面，在呼叫我的Library的時候始終沒辦法搞定這個CString的引數，後來沒辦法，只能讓我給改成string 型別的引數，原因是這樣的，CString是MFC 特有的類，屬於Win32 API，是微軟為了方便windows下的開發自己開發的庫，而string 屬於標準C／C++庫，與平臺無關，所以，Header file 中最好不要用到Win32 API ，至於函式的實體或著函式的實現部分是可以使用Win32 API的。另外，MFC 的開發是可以同時使用這兩個庫的。

• 編譯器環境的設定：

        開發Library的同時，一般會寫測試程式來驗證Library的，這時候我們可以將兩個工程放到一個Solution下進行關聯，設定編譯順序，啟動項，可以在library的工程下設定編譯完成後Copy 相關header file，DLL和Lib檔案到測試程式相關目錄，從而保證測試程式每次都是使用最新的Library，另外，除了相關檔案的Copy外，兩個工程儘量不要有路徑上的關聯，以便兩個工程可以分開編譯執行，因為很多時候我們給出去的只是header file，DLL和Library, 或者相應的EXE，而不是整個原始碼。

• 程式碼的移植問題：

         之前只是從VS2002移植到VS2010成功過，但是從VS2010移植到VS2002可能就要重新建立工程，複製相應＊.c 和＊.h檔案了,另外VS2002開發的library連結在VS2010下使用出過問題，據同事說，不能直接連結，經常會出現問題，我這沒有機會驗證，只能等待進一步學習了。

• 版本管理問題：

        作為新手的我剛開始工作的時候總是對這個問題沒有足夠的關注，導致之後時常會出現一些問題，比如相應的firmware，library 和測試程式對不上，很多時間都花在這個上面，作為開發者，在開發的過程中我們當然比較清楚我們開發的東西的特點，但是時間一長真的會忘記的，有時候需要修改一個模組一個不注意就影響到了其它模組或是其他版本，尤其是版本比較多的時候，所以版本的管理很重要，雖然沒有什麼技術上的挑戰，但是這個問題一定要注意。