从BCB5开始，我有一系列使用C ++ Builder开发的Win32 VCL应用程序，希望将它们移植到ECB2009或者现在称为的任何版本。

我的某些应用程序使用了旧的TNT / TMS unicode组件，因此我在整个代码中很好地混合了AnsiStrings和WideStrings。新版本引入了UnicodeString，以及一系列#define，它们改变了诸如c_str之类的函数的行为方式。

我想以一种尽可能向后兼容的方式修改我的代码，以便在必要时仍可以在BCB2007上编译和运行相同的代码库(以非Unicode方式)。

特别关注的领域是：

• 向/从Win32 API函数传递字符串
• 与TXMLDocument互操作
• 用于RS232通讯等的"原始"字符串

我正在寻找的指南而不是一刀切的，可以用来减轻迁移的影响，同时尽可能地保持向后兼容性。

如果还没有这样的指导方针，也许我们可以在这里制定一些指导方针？

解决方案

最大的问题是与C ++ Builder 2009和早期版本的兼容性，Unicode有所不同，但项目配置文件也已更改。根据我在CodeGear论坛上一直关注的讨论，在这个问题上没有太多选择。

如果我们尚未开始，我认为应该首先开始C ++ Builder 2009发行说明。

看到的最大的事情是TCHAR映射(到wchar或者char)。使用STL字符串变体可能会有所帮助，因为这两个版本之间的区别应该不大。映射也存在于C ++ Builder 2007中(带有tchar标头)。

对于不需要显式Ansi或者显式Unicode的任何代码，应考虑尽可能使用System :: String，System :: Char和System :: PChar typedef。这将有助于简化许多迁移，并且它们可以在以前的版本中使用。

将System :: String传递给API函数时，必须考虑Project选项中新的" TCHAR maps to"设置。如果在" TCHAR映射到"设置为" wchar_t"时尝试传递AnsiString :: c_str()，或者在" TCHAR映射到"设置为" char"时传递UnicodeString :: c_str()类型转换。如果将" TCHAR映射到"设置为" wchar_t"。从技术上讲，UnicodeString :: t_str()的作用与TCHAR在API中的作用相同，但是如果我们滥用它，t_str()可能非常危险(当" TCHAR映射到"设置为" char"时，t_str()会转换UnicodeString的内部数据传递给Ansi)。

对于"原始"字符串，可以使用新的RawByteString类型(尽管我不建议这样做)或者TBytes(建议使用字节数组)。首先，我们不应该将Ansi / Wide / UnicodeString用于非字符数据。大多数人在过去的版本中都将AnsiString用作临时数据缓冲区。不要再这样做了。这一点特别重要，因为AnsiString现在可以识别代码页，因此，在我们最不希望的时候，数据可能会转换为其他代码页。