delphi - 要将复杂的应用程序从 C++Builder 2007 升级到 2010，我需要了解哪些信息？

Question

我公司的主要应用程序大部分是用C++编写的(带有一些Delphi代码和组件)。我们将从 RAD Studio 2007 升级到 2010，以便在大约一周后开始发布下一个版本。我需要了解什么才能确保升级顺利进行？

到目前为止我想到的要点是:

• 统一码。这个看起来真的很复杂。我们的应用程序包含 std::string-s 和 AnsiString-s 的可怕组合，以及它们之间的强制转换。我对此有很多疑问，例如“wstring 是否能够容纳 UnicodeString 可以容纳的所有内容，我们是否应该只进行搜索/替换”，或者“我们是否应该完全避免所有 C++ 字符串类型并使用 UnicodeString”、“我们可以吗？”将所有事件处理程序更改为使用 String，尽管现有的 .HPPs 事件处理程序方法原型(prototype)已编译器翻译为 AnsiString”，具体到基础知识，例如“我们应该为所有字符串添加 L 前缀，还是编译器足够聪明，启用 Unicode 来使用 Unicode 字符串”等。对此的任何见解都将非常感激。

  我们还需要向后兼容性。我们的应用程序使用自己的二进制元组格式，当前将字符串存储为字节数组。我需要升级它以读取旧文件，并且可能还写入新的 Unicode 字符串。如何处理嵌入二进制格式的 Unicode 字符串？是否有任何通用方法可以将 UnicodeString 指向字节数组，该数组最初可能写为 ANSI 字节或 Unicode，并且它会弄清楚它们是什么？

• 第三方组件。我们使用SpTBX主要是，而且看起来是兼容的。

• 项目升级。 Codegear 论坛中的标准建议似乎是在升级时手动重新创建所有项目文件。这是一项巨大的工作量(我们的主应用程序中的 7 个项目(主要是库)，加上六个 DLL，很多文件。)有什么方法可以自动执行此操作吗？

• 链接器看起来怎么样？传统上，我们在链接器随机崩溃或耗尽资源方面遇到了很多麻烦，尽管在 2007 年情况有所好转。这是我们的主应用程序被分成几个库的原因之一 - 链接器不能(希望“不能，但现在可以”？)以其他方式处理它。

• 我知道有一个新的类型库编辑器和格式(它存储 IDL，即文本，并动态生成 TLB？)这如何处理使用 TLB 升级现有 COM 项目？我们有内置于 C++ 应用程序中的 Delphi 代码和 TLB。

• 还有什么我应该考虑或注意的吗？

我发现:

• 2007 and 2010 co-existing 。我不确定我是否相信这个答案，因为我之前在同一台机器上使用 2006 年和 2007 年时遇到过问题。
• 关于 Unicode 的几个答案:writing strings with 2009和 generic transition to Unicode text但没有一个是问题的答案，也不是 C++Builder 特定的部分。
• This question about guidelines upgrading to 2009尽管这些答案很有帮助，但它们并没有回答上述所有与 Unicode 相关的问题。
• [编辑:添加] Codegear 文档 Unicode in RAD Studio和 things to look for when converting to Unicode

Answer 1

Project upgrades. The standard advice in the Codegear forums seems to be to manually recreate all project files when upgrading. This is an awful lot of work (7 projects (mostly libs) in our main app, plus half a dozen DLLs, a lot of files.) Is there any way to automate this?

有:只需使用 IDE 的项目导入器:)
说真的，我只是尝试导入项目，然后再去调查是否不起作用。

How's the linker look? We traditionally have a lot of trouble with the linker randomly crashing or running out of resources, though it got a lot better in 2007. This is one reason our main application is split into several libs - the linker cannot (hopefully, "could not, but now can"?) handle it otherwise.

自 C++Builder 2009 以来，我在使用 ILINK 时几乎不再遇到任何问题。我偶尔会读到其他人遇到内存不足错误，但新闻组中的某人发现了一种解决方法:

https://forums.embarcadero.com/thread.jspa?messageID=140012&tstart=0#140012

另外，正如您可以阅读的那样 here ，编译器有了一个新选项(-Cx)来控制它分配的最大内存量。

I know there's a new type library editor and format (it stores the IDL, ie text, and generates the TLB dynamically?) How well does this handle upgrading existing COM projects with a TLB?

应该可以顺利工作。

I have lots of questions about this, such as "is wstring capable of holding everything a UnicodeString can, and should we just do a search/replace"

是的，在Windows平台上，wchar_t通常是16位大，这意味着它足以容纳UTF-16，即UnicodeString。

or "should we avoid all C++ string types altogether and use UnicodeString"

取决于您的代码需要的可移植性。无论如何，只要您只需要字符串类型，请使用“String”，而不是“UnicodeString”。

"can we change all event handlers to use String though the existing .HPPs were compiler-translated to AnsiString"

首先，您不应该重复使用旧版本 DCC 生成的 .hpp 文件!对于 Delphi 中使用 String 类型的事件处理程序，必须使用 UnicodeString。如上所述，只需使用“String”，您的代码将适用于 C++Builder 的 ANSI 和 Unicode 版本。

right down to basics such as "should we prefix all strings with L, or is the compiler smart enough with Unicode enabled to use Unicode strings"

编译器不会转换您的字符串(这会与语言标准冲突)，但 AnsiString 和 UnicodeString 都有 char* 和 wchar_t* 字符串文字的复制构造函数重载。即，以下内容将起作用:

AnsiString as = L"foo";
UnicodeString us = "bar";

但是，整堆 printf()/scanf() 函数不会以这种方式工作； AnsiString::sprintf() 采用 const char*，UnicodeString::sprintf() 采用 const wchar_t*。

如果您经常使用 sprintf()，您可能会发现我的 CbdeFormat 库很有用；刚刚读过my article on the subject .