6

I have a range of Win32 VCL applications developed with C++Builder from BCB5 onwards, and want to port them to ECB2009 or whatever it's now called.

Some of my applications use the old TNT/TMS unicode components, so I have a good mix of AnsiStrings and WideStrings throughout the code. The new version introduces UnicodeString, and a bunch of #defines that change the way functions like c_str behave.

I want to modify my code in a way that is as backwards-compatible as possible, so that the same code base can still be compiled and run (in a non-unicode fashion) on BCB2007 if necessary.

Particular areas of concern are:

  • Passing strings to/from Win32 API functions
  • Interop with TXMLDocument
  • 'Raw' strings used for RS232 comms, etc.

Rather than knife-and-fork the changes, I'm looking for guidelines that I can apply to ease the migration, while keeping backwards compatibility wherever possible.

If no such guidelines already exist, maybe we can formulate some here?

4

2 回答 2

4

最大的问题是对 C++Builder 2009 和以前版本的兼容性，Unicode 差异是一些，但项目配置文件也发生了变化。根据我在CodeGear 论坛上的讨论，在这件事上没有太多选择。

如果您还没有这样做，我认为首先要开始的地方是C++Builder 2009 发行说明。

看到的最大的事情是 TCHAR 映射（到 wchar 或 char）；使用 STL 字符串变体可能会有所帮助，因为它们在两个版本之间应该没有太大差异。该映射也存在于 C++Builder 2007 中（带有 tchar 标头）。

于 2008-09-30T13:25:26.873 回答
2

对于不需要显式 Ansi 或显式 Unicode 的任何代码，您应该考虑尽可能使用 System::String、System::Char 和 System::PChar 类型定义。这将有助于减轻大量迁移，并且它们可以在以前的版本中使用。

将 System::String 传递给 API 函数时，您必须考虑项目选项中新的“TCHAR 映射到”设置。如果您尝试在“TCHAR 映射到”设置为“wchar_t”时传递 AnsiString::c_str()，或者当“TCHAR 映射到”设置为“char”时传递 UnicodeString::c_str()，则必须执行适当的操作类型转换。如果您将“TCHAR 映射到”设置为“wchar_t”。从技术上讲，UnicodeString::t_str() 与 API 中的 TCHAR 所做的事情相同，但是如果您滥用 t_str() 可能会非常危险（当“TCHAR 映射到”设置为“char”时，t_str() 会转换UnicodeString 的内部数据到 Ansi)。

对于“原始”字符串，您可以使用新的 RawByteString 类型（尽管我不推荐它），或者使用 TBytes 代替（这是一个字节数组 - 推荐）。您不应该将 Ansi/Wide/UnicodeString 用于非字符数据。在过去的版本中，大多数人使用 AnsiString 作为临时数据缓冲区。不要再这样做了。这一点尤其重要，因为 AnsiString 现在可以识别代码页，因此您的数据可能会在您最不期望的时候转换为其他代码页。

于 2009-06-04T01:08:51.157 回答