我有一系列使用C++ Builder從BCB5開發的Win32 VCL應用程序，並且希望將它們移植到ECB2009或現在稱爲的任何應用程序。是否有更新用於C++ Builder 2009的C++ Builder應用程序的指導原則？
我的一些應用程序使用舊的TNT/TMS unicode組件，因此我在整個代碼中都有很好的AnsiStrings和WideStrings組合。新版本引入了UnicodeString，並且一些#define改變了像c_str這樣的函數的行爲方式。
我想以儘可能向後兼容的方式修改我的代碼，以便在必要時仍然可以在BCB2007上編譯和運行相同的代碼庫（以非Unicode格式）。關注
具體領域是：
與其說是刀叉式的更改，我正在尋找適用於緩解遷移的準則，並儘可能保持向後兼容性。
如果沒有這樣的指導方針已經存在，也許我們可以在這裏制定一些？
最大的問題是C++ Builder 2009和以前版本的兼容性，Unicode的差異是一些，但項目配置文件也發生了變化。從我在CodeGear forums的討論中，在這件事上沒有太多的選擇。
我覺得第一個開始的地方是C++Builder 2009 release notes，如果你還沒有這樣做的話。最大的問題是TCHAR映射（對wchar或char）;使用STL字符串變種可能是一種幫助，因爲它們在兩個版本之間應該沒有太大差異。該映射也存在於C++ Builder 2007中（使用tchar頭文件）。
對於任何不需要明確表示Ansi或Explicit Unicode的代碼，應儘可能考慮使用System :: String，System :: Char和System :: PChar typedefs。這將有助於緩解大量遷移，並且可以在以前的版本中使用。
將System :: String傳遞給API函數時，必須考慮項目選項中新的「TCHAR貼圖」設置。如果在「TCHAR maps to」設置爲「wchar_t」時嘗試傳遞AnsiString :: c_str（），或者在「TCHAR maps to」設置爲「char」時傳遞了UnicodeString :: c_str（），則必須執行適當的類型轉換。如果您有「TCHAR映射到」設置爲「wchar_t」。從技術上講，UnicodeString :: t_str（）與TCHAR在API中的作用相同，但如果誤用它（當「TCHAR映射到」設置爲「char」時，t_str（）可能會非常危險，t_str UnicodeString的內部數據給Ansi）。
對於「原始」字符串，可以使用新的RawByteString類型（儘管我不推薦使用它），或者使用TBytes（它是一個字節數組 - 推薦）。你不應該使用Ansi/Wide/UnicodeString作爲開頭的非字符數據。大多數人在過去的版本中使用AnsiString作爲臨時數據緩衝區。不要那樣做了。這一點尤其重要，因爲AnsiString現在可以支持代碼頁，因此您的數據在最不經意的時候可能會轉換爲其他代碼頁。