我有一系列使用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现在可以支持代码页，因此您的数据在最不经意的时候可能会转换为其他代码页。