Unicode 是否有更新C+的指南+；C++；建筑商2009？

从BCB5开始，我用C++Builder开发了一系列Win32 VCL应用程序，并希望将它们移植到ECB2009或现在称之为什么的版本

我的一些应用程序使用旧的TNT/TMS unicode组件，因此我在代码中很好地混合了ansistring和wideString。新版本引入了UnicodeString，以及一系列改变c#str等函数行为方式的#定义

我希望以一种尽可能向后兼容的方式修改代码，以便在必要时仍然可以在BCB2007上编译和运行相同的代码库（以非unicode方式）

特别值得关注的领域包括：

• 向Win32 API传递字符串/从Win32 API传递字符串 功能
• 与TXMLDocument的互操作
• 用于RS232通信等的“原始”字符串

我寻找的不是刀叉式的改变，而是可以用来简化迁移的指导原则，同时尽可能保持向后兼容性

---

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

最大的问题是C++Builder 2009和以前版本的兼容性，Unicode的差异是一些，但是项目配置文件也发生了变化。从我一直关注的讨论来看，在这个问题上没有太多的选择

我认为，如果你还没有这样做的话，首先要开始的是

---

看到的最大的事情是TCHAR映射（到wchar或char）；使用STL字符串变体可能会有所帮助，因为这两个版本之间应该没有太大差异。在C++ Builder 2007中也存在映射（Tchar头）。对于不需要明确的ANSI或解释Unicode的任何代码，您应该尽可能地考虑使用String：String、Stry::Car和Strase: PChar typedefs。这将有助于简化大量迁移，而且它们在以前的版本中也可以工作

将System:：String传递给API函数时，必须考虑项目选项中的新“TCHAR maps to”设置。如果尝试在“TCHAR maps to”设置为“wchar_t”时传递AnsiString:：c_str（），或在“TCHAR maps to”设置为“char”时传递UnicodeString:：c_str（），则必须执行适当的类型转换。如果将“TCHAR映射到”设置为“wchar\u t”。从技术上讲，UnicodeString:：t_str（）的作用与TCHAR在API中的作用相同，但是如果误用它，t_str（）可能非常危险（当“TCHAR maps to”设置为“char”时，t_str（）将UnicodeString的内部数据转换为Ansi）

对于“raw”字符串，您可以使用新的RawByteString类型（尽管我不推荐），也可以使用TBytes（建议使用字节数组）。您不应该首先对非字符数据使用Ansi/Wide/UnicodeString。在过去的版本中，大多数人使用Anistring作为临时数据缓冲区。不要再那样做了。这一点尤其重要，因为ansisting现在可以识别代码页，因此您的数据可能会在您最不希望的时候转换为其他代码页