代码之家  ›  专栏  ›  技术社区  ›  Roddy

是否有更新C++ Builder 2009应用程序的指导原则?

  •  6
  • Roddy  · 技术社区  · 16 年前

    我有一个Win32 VCL应用程序从BCB5开始用C++ Builder开发,并希望将它们移植到ECB2009或它现在所调用的任何东西。

    我的一些应用程序使用旧的tnt/tms unicode组件,因此我在代码中很好地混合了ansistring和widestring。新版本引入了unicodestring,一系列的定义改变了c_str等函数的行为方式。

    我希望以尽可能向后兼容的方式修改代码,以便在必要时仍然可以在bcb2007上编译和运行相同的代码基(以非unicode方式)。

    特别关注的领域是:

    • 向/从win32 api传递字符串 功能
    • 与Txmldocument互操作
    • 用于rs232通信等的“原始”字符串。

    与刀叉式的改变不同,我正在寻找可以应用的指导原则来简化迁移,同时尽可能保持向后兼容。

    如果还没有这样的指导方针,也许我们可以在这里制定一些?

    2 回复  |  直到 11 年前
        1
  •  4
  •   Kris Kumler    16 年前

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

    我想,如果你还没有这样做的话,首先要做的是 C++Builder 2009 release notes .

    所看到的最大的事情是t char映射(到wchar或char);使用stl字符串变体可能会有所帮助,因为这两个版本之间不应该有太大的差异。在C++Builder 2007中也存在映射(TCHAR头)。

        2
  •  2
  •   Remy Lebeau    16 年前

    对于不需要显式ANSI或显式Unicode的任何代码,应考虑尽可能使用System::字符串、System::char和System::pchar typedefs。这将有助于简化大量的迁移,而且它们可以在以前的版本中工作。

    将system::string传递给api函数时,必须考虑项目选项中的新“tchar maps to”设置。如果试图在“t char maps to”设置为“wchar_t”时传递ansistring::c_str(),或者在“tchar maps to”设置为“char”时传递unicodestring::c_str(),则必须执行适当的类型转换。如果您将“tchar maps to”设置为“wchar_t”。从技术上讲,unicodestring::t_str()的作用与t char在api中的作用相同,但是如果您误用了t_str(),则会非常危险(当“tchar maps to”设置为“char”时,t_str()会将unicodestring的内部数据转换为ansi)。

    对于“raw”字符串,可以使用新的rawbytestring类型(尽管我不建议使用它),或者使用tbytes(这是一个字节数组-建议使用)。对于非字符数据,不应首先使用ansi/wide/unicodestring。在过去的版本中,大多数人使用ansistring作为临时数据缓冲区。别再那样做了。这一点特别重要,因为ansistring现在可以识别代码页,因此您的数据可能会在您最不期望的时候转换为其他代码页。