【问题标题】:Visual Studio C++ WChar_t library conflictVisual Studio C++ WChar_t 库冲突
【发布时间】:2021-04-18 13:31:47
【问题描述】:

我正在使用 Visual Studio 开发一个 C++ 项目。目前我正在使用 2 个库,其中一个(我们称之为“no.lib”)需要将“将 WChar_t 视为内置类型”属性设置为“否”,而另一个('yes.lib') 需要它是'yes'。因此,无论我将属性设置为什么,我的程序都将无法编译或无法运行。

我尝试了this thread 中描述的解决方案,但它对我不起作用。另外,如果可能的话,我想保持关闭,因为我的整个项目都是基于 no.lib 的,而我只使用了 yes.lib 的两个功能。

我有什么选择?

【问题讨论】:

标签: c++ visual-studio visual-c++ dll wchar-t


【解决方案1】:

Microsoft Docs给出解释:

如果您编写的新代码必须与旧代码互操作 仍然使用 wchar_t 的 typedef 版本,可以提供重载 对于 wchar_t 的 unsigned short 和 __wchar_t 变体,所以 您的代码可以与使用 /Zc:wchar_t 或 没有它编译的代码。否则,您必须提供两个 库的不同版本,一种有,一种没有 /Zc:wchar_t 启用。即使在这种情况下,我们也建议您构建较旧的代码 通过使用与编译新代码相同的编译器。绝不 混合使用不同编译器编译的二进制文件。

当指定 /Zc:wchar_t 时,_WCHAR_T_DEFINED 和 _NATIVE_WCHAR_T_DEFINED 符号已定义。有关详细信息,请参阅预定义宏。

我建议您可以尝试添加以下代码:

#ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#define _WCHAR_T_DEFINED
#endif

在编译 C++ 文件时,如果 /Zc:wchar_t 生效,则编译器会预先定义 _WCHAR_T_DEFINED。如果/Zc:wchar_t- 有效,它不会 - 所以上面的 sn-p 应该也能很好地与 C++ 一起工作。


你可以参考这个麻烦的方法。下面是一个例子:

实际上,lib中的一个函数使用wchar_t*作为字符串,另一个lib使用unsigned short *作为字符串。

如果不重新编译lib,解决办法是改头文件。现在这两个库的头文件中的函数声明都声明使用wchar_t*作为字符串。

但实际上lib导出的函数之一使用unsigned short *作为字符串。

如果A库编译时使用“wchar_t作为内置类型”编译,A库头文件有如下函数声明

void FunctionA(const wchar_t *wsz);

B库编译时用“wchar_t not as a built-in type”编译,B库头文件有如下函数声明

void FunctionB(const wchar_t *wsz);

由于B lib是用“wchar_t not as a built-in type”编译的,所以B lib头文件中的wchar_t实际上是unsigned short。

所以现在新建一个项目,设置为“wchar_t是内置类型”,然后引入A和B两个库,然后修改B库的头文件。

改为:

void FunctionB(const unsigned short *wsz);

不会有链接错误。就是打电话的时候有点麻烦。

wchar_t wsz[] = L"Hello";
FunctionA(wsz);
FunctionB((const unsigned short *)wsz);

【讨论】:

  • 感谢您的回复@Barnet Chou 不幸的是,问题仍然存在。如果我将 'Treat WChar_t As Built in Type' 设置为 no,我会在编译时收到链接错误。如果设置为 yes,则在运行时发生错误(我的 dll 无法加载)。无论您提供或不提供您提供的代码,此行为都是相同的。还有什么我需要改变的吗?
  • 我建议你可以试试这个方法。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-09-23
  • 1970-01-01
  • 2013-01-14
  • 2020-05-12
  • 1970-01-01
  • 2018-10-20
  • 1970-01-01
相关资源
最近更新 更多