什么我需要知道从C ++ Builder的2007升级复杂的应用程序,以2010?(What do

2019-07-05 14:43发布

我公司的主要的应用程序主要用C ++编写(一些Delphi代码和组件)。 我们从公司的RAD Studio 2007升级到2010的下一个版本,在一个星期左右开始。 什么是我需要知道,以确保本次升级的顺利进行?

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

  • Unicode格式。 这一个看起来复杂。 我们的应用程序中包含的std :: string-S和AnsiString类型-S的铸件,并从他们可怕的组合。 我有很多关于这个问题,如“是wstring的能容纳一切的UnicodeString可以,而且应该,我们只是做一个查找/替换”,或“我们应该避免所有的C ++字符串类型完全和使用的UnicodeString”,“我们能改变所有的事件处理程序使用字符串,虽然现有的.HPPs事件处理方法原型编译器转换为AnsiString类型“一直到基础知识,如”我们应该前缀的所有字符串与L,或者是编译器足够聪明与支持Unicode使用Unicode字符串”等对此有何见解将非常感激。

    我们还需要向后兼容性。 我们的应用程序将使用当前存储字符串作为字节数组自己的二进制元组格式。 我需要升级这个读取旧文件,以及是否可能写入新的Unicode字符串为好。 如何处理嵌入在二进制格式的Unicode字符串? 有没有通用的方法,我可以在一个字节数组,可最初写成无论是ANSI字节或Unicode点一的UnicodeString,它会找出它们是什么?

  • 第三方组件。 我们使用SpTBX为主,这似乎是兼容的。

  • 项目升级。 在CodeGear的论坛标准的建议似乎是在升级时手动重新创建所有项目文件。 这是一个可怕的很多工作(7个项目(主要是库)在我们的主应用程序,加上半打的DLL, 的文件。)有什么办法来自动完成这个?

  • 怎么样链接看? 我们通常有一个很大的麻烦与连接随机崩溃或资源耗尽,虽然它在2007年。这得到了很多更好的一个原因,我们的主要应用被分为若干个库 - 链接器不能(有希望,“不能,但现在“?),否则处理它。

  • 我知道有一个新的类型库的编辑与格式(它存储的IDL,即文本,并动态生成的TLB?)这在多大程度上手柄升级现有的COM项目有TLB? 我们有Delphi代码和内置到C ++应用程序TLB。

  • 还有什么我应该考虑和注意的?

我已经找到:

  • 2007和2010共存 。 我不知道我相信这个答案,因为我已经在同一台机器上有过问题,2006年和2007年。
  • 关于Unicode几个答案: 与2009年写的字符串 ,并以Unicode文本通用化 ,但没有是担忧的答案,或C ++ Builder的特定部分的。
  • 这是关于指导升级到2009年的问题 ,但尽管答案是有帮助的,他们不回答以上所有的Unicode相关的问题。
  • [编辑:添加] CodeGear的证件统一在RAD Studio中和事情,寻找转换为Unicode时

Answer 1:

项目升级。 在CodeGear的论坛标准的建议似乎是在升级时手动重新创建所有项目文件。 这是一个可怕的很多工作(7个项目(主要是库)在我们的主应用程序,加上半打的DLL,很多的文件。)有什么办法来自动完成这个?

有,这就是只使用IDE的项目进口商:)
说真的,我只是尝试导入项目,然后再去调查,如果似乎工作不。

怎么样链接看? 我们通常有一个很大的麻烦与连接随机崩溃或资源耗尽,虽然它在2007年。这得到了很多更好的一个原因,我们的主要应用被分为若干个库 - 链接器不能(有希望,“不能,但现在“?),否则处理它。

我已经与ILINK几乎没有麻烦了,因为C ++ Builder的2009年,我偶尔读到别人经历了内存不足的错误,但有人在新闻组中发现了一个解决办法:

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

此外,你可以阅读这里 ,编译器有一个新的选项(-Cx)来控制内存的最大金额它分配。

我知道有一个新的类型库的编辑与格式(它存储的IDL,即文本,并动态生成的TLB?)这在多大程度上手柄升级现有的COM项目有TLB?

应该工作顺利。

我有很多关于这个问题,如“是wstring的能容纳一切的UnicodeString就可以了,我们应该做一个查找/替换”

是的,在Windows平台上的wchar_t通常是16位的大,这意味着它足以举办的UTF-16的UnicodeString是。

或“我们应该避免所有的C ++字符串类型完全和使用的UnicodeString”

取决于你的代码如何移植必须这样做。 在任何情况下,无论你只需要一个字符串类型,使用“字符串”,而不是“的UnicodeString”。

“我们可以把事件处理程序使用字符串,虽然现有的.HPPs被编译器转换为AnsiString类型”

首先,你永远不应该再使用.HPP老版本的DCC生成的文件! 对于使用Delphi中的字符串类型的事件处理程序,您必须使用的UnicodeString。 如上所述,简单地用“串”,你的代码将同时适用于C ++ Builder中的ANSI和Unicode版本。

一直到基础知识,如“我们应该前缀以L所有字符串,或者是编译器足够聪明与支持Unicode使用Unicode字符串”

编译器不转换您的字符串(它会与语言标准冲突),但两者AnsiString类型和的UnicodeString做有两个字符*和wchar_t的*字符串文字拷贝构造函数重载。 即,下面的工作:

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

究竟会不会以这种方式工作,不过,是的printf()/ scanf函数的一大堆()函数; AnsiString类型:: sprintf的()需要为const char *的UnicodeString :: sprintf的()采用常量为wchar_t *。

如果您使用的sprintf()有很多,你会发现我的CbdeFormat库有用的; 刚读我关于这个问题的文章 。



Answer 2:

你不说什么你的二进制元组格式的数据字符串是:是否有必要为他们存储Unicode? 当我从D2007转变为D2009我能够保持只有系统ANSI字符串的某些部分。

如果需要存储Unicode,那么你需要检查,如果你现有的数据可与格式如UTF-8兼容。 如果存储在现有的数据文件值的范围提出一个问题,那我就做你的下一次升级做任何旧的数据文件的一次性转换,读老AnsiString类型的数据和写回为UTF-8到不同,或通过修改相应的文件标题数据文件名或扩展。 我一直在版本管理数据文件很长一段时间,只是为了让这种处理的变化。

我才刚刚开始BCB2010项目,所以不能在你的其他问题发表意见,但我肯定有困难,从D2007到D2009升级Delphi工程 - 尽管我可以通过编辑项目文件中,这仅仅是XML来解决这个问题。

祝你好运与转换;-)



Answer 3:

Unicode格式。 这一个看起来很复杂。 我们的应用程序中包含的std :: string-S和AnsiString类型-S的铸件,并从他们可怕的组合。 我有很多关于这个问题,如“是wstring的能容纳一切的UnicodeString就可以了,我们应该做一个查找/替换”

std::wstring包含wchar_t*字符串,就像System::UnicodeString一样。

我们应该避免所有的C ++字符串类型完全和使用的UnicodeString

这是由你来决定。 char*字符串仍支持。 你是不是被迫的一切移植到Unicode。

我们可以把事件处理程序使用字符串,虽然现有的.HPPs被编译器转换为AnsiString类型

不,你不能改变自动管理事件处理程序使用System::String别名。 所有的IDE版本会抱怨说。 您必须手动更新您的事件处理程序的声明和实现使用UnicodeString参数而不是AnsiString在适当的时候的参数。 这也意味着你不能共享的DFM和单位.h文件在多个版本的IDE,要么(你不应该这样做无论如何)。

我们应该前缀的所有字符串与L,或者是编译器足够聪明与支持Unicode使用Unicode字符串

不,如果你声明字符串常量或字符常量没有一个L前缀,该数据仍然会interpretted为ANSI。 这并没有改变。 你可以,但是,通过安思数据System::UnicodeString (但不是std::wstring ),它会自动转换为Unicode。 但是你必须要小心,因为它会使用操作系统的默认Ansi代码页来解释数据。 只要你的Ansi数据仅仅只使用ASCII字符,那么你会好起来的。 否则,如果您正在使用非ASCII字符,那么你最好将数据放入一个System::AnsiStringTSystem::RawByteString (均在CB2009引入)已指定了正确的编码,然后赋值给您的System::UnicodeString变量。 相关的代码页将被用来代替用于转换操作系统的默认代码页。

我们还需要向后兼容性。 我们的应用程序将使用当前存储字符串作为字节数组自己的二进制元组格式。 我需要升级这个读取旧文件,以及是否可能写入新的Unicode字符串为好。 如何处理嵌入在二进制格式的Unicode字符串?

如果您的元组期待8位字符,那么你必须确保任何结构声明和这样使用char ,而不是wchar_t字符。 如果你需要存储Unicode字符串,但需要保持8位兼容,那么你应该编码您的Unicode字符串转换为UTF-8第一次(可以使用System::UTF8String字符串类型来帮助你-在CB2009开始,它是一个真正的UTF-8字符串现在)。 只要您不使用非ASCII字符,那么你的旧应用程序将无法知道其中的差别,以ASCII字符编码为-是UTF-8。 如果你想存储原始Unicode数据,但是,那么你的元组将需要一个标志的地方(如果没有的话)表示字符串数据是否存储为ANSI或Unicode,和你的应用程序将不得不寻找一个标志。

有没有通用的方法,我可以在一个字节数组,可最初写成无论是ANSI字节或Unicode点一的UnicodeString,它会找出它们是什么?

号你要知道实际字节编码事前。 如果你通过一个内存地址System::AnsiStringstd::string ,它要承担ANSI字符。 如果你通过了相同的内存地址, System::UnicodeStringstd::wstring ,它要承担的Unicode字符来代替。

第三方组件。 我们使用SpTBX为主,这似乎是兼容的。

就像使用(除迁移2006至2007年)以前的所有版本中,你必须将需要重新编译为2010的任何第三方组件,手动或者(如果你有他们的源代码),或者由各自的供应商。

项目升级。 在CodeGear的论坛标准的建议似乎是在升级时手动重新创建所有项目文件。

是。 这仍然适用。

我知道有一个新的类型库的编辑与格式(它存储的IDL,即文本,并动态生成的TLB?)

.TLB文件没有在使用的所有了。 新系统运行在.ridl(精简IDL)文件现在。 编译期间,.ridl产生直接可执行的二进制资源的正确的TypeLibrary信息。 没有的.tlb文件生成。

这在多大程度上手柄升级现有的COM项目有TLB? 我们有Delphi代码和内置到C ++应用程序TLB。

我不记得是否CB2010(或CB2009,对于这个问题)能够直接使用现有的预.TLB文件。 我不认为他们能。 你可以,但是,贯穿tlibimp.exe .tlb文件,它会导出.ridl文件。 或者你也可以复制从TLB编辑器中的IDL文在过去的版本,并将其手动粘贴到新.ridl文件。 无论哪种方式,你可以那么.ridl ILE添加到您的CB2010项目。

2007年和2010年共存。 我不知道我相信这个答案,因为我已经在同一台机器上有过问题,2006年和2007年。

这就是为什么我安装同一台物理机器上的多个IDE版本时,使用虚拟机。



Answer 4:

是符合效益提升的成本是多少?

为什么不从哪里开始新组件将在新的平台上开发逐步升级。 通过不同的互操作助手整合新组件的旧版本。

这种方法是建议vb6开发谁正在考虑有关升级到vb.net



文章来源: What do I need to know to upgrade a complex application from C++Builder 2007 to 2010?