UnicodeString兼容性问题

Lun*_*din 4 c++ unicode vcl c++builder

我正在将一个较旧的项目从C++ Builder 2009移植到XE5.在旧项目中,Unicode字符串的编译器选项设置为" _TCHAR映射到:char".这在旧项目中运行良好.

移植时,我在XE5中设置了相同的编译器选项.但我仍然得到这样的代码编译器错误:

std::string str = String(some_component.Text).t_str();
Run Code Online (Sandbox Code Playgroud)

这会出现以下错误:

[bcc32 Warning] file.cpp(89):W8111访问不推荐使用的实体'UnicodeString :: t_str()const'

[bcc32错误] file.cpp(89):E2285无法找到'operator string :: =(wchar_t*)'的匹配项

显然XE5已经决定String::t_str()应该给我一个wchar_t*而不是一个char*,即使我已经设置了如上所述的编译器选项.

我该如何解决这个问题?

我很清楚C++ Builder已经采取了内部使用Unicode的步骤(即使在2009版本中),但这是一个200k LOC的旧项目.将其更新为Unicode将是一项非常低优先级的陡峭任务.

编辑

我可以通过更改代码来使其工作

std::string str = AnsiString(some_component.Text).c_str();
Run Code Online (Sandbox Code Playgroud)

但这意味着我必须在很多地方更改代码.有没有更好的方法不涉及重写代码?

Rem*_*eau 8

何时UnicodeString::t_str()首次在CB2009中引入,它返回一个char*wchar_t*取决于TCHAR映射到什么.为了返回a char*,它改变了UnicodeString的内部数据以使其成为Ansi(从而打破了UnicodeString是Unicode字符串的合同). 这是暂时的迁移目的,而人们仍在重写代码以支持Unicode.这种破坏是可以接受的,因为RTL具有处理Ansi编码的UnicodeString(和Unicode编码的AnsiString)值的特殊逻辑.但是,这是危险的代码.在几个版本之后,当人们有足够的时间进行迁移时,此RTL逻辑被删除UnicodeString::t_str()并被锁定为wchar_t*仅匹配UnicodeString::c_str(). 不要t_str()再使用了! 这就是它现在被标记为已弃用的原因.如果需要将UnicodeString传递给需要Ansi数据的东西,转换为中间AnsiString是正确而安全的方法.这就是现在的样子.