libboost_thread-vc142-mt-x64-1_82.lib(thread.obj) : error LNK2038: 检测到“_CRT_STDIO_ISO_WIDE_SPECIFIERS”的不匹配项: 值“0”不匹配值“1”(AcadStr.obj 中) 1> 正在创建库 x64ReleaseArxDbg.lib 和对象 x64ReleaseArxDbg.exp : fatal error LNK1319: 检测到 1 个不匹配项 1>已完成生成项目“ArxDbg.vcxproj”的操作 - 失败。 ========== 全部重新生成: 成功 0 个，失败 1 个，跳过 0 个 ========== 天天都是这种问题 以Debug或Release方式运行，会出现很多问题，我们逐一解决。
c 宏定义_CRT_STDIO_ISO_WIDE_SPECIFIERS
代码语言：javascript复制第三方库宏定义冲突解决办法
假如项目用到的两个第三方库，lib_a和lib_b中，头文件a.h和b.h存在宏定义冲突的问题。
那么可以创建一个源文件c.cpp和c.h，将lib_a或lib_b的头文件封装在c.cpp中，在c.h中提供新的接口声明方便自己程序调用即可。https://blog.csdn.net/RNAMatrix/article/details/5765462
c 预处理器宏定义不匹配 (1) 预处理命令问题，表现为：
LNK2038 检测到“_CRT_STDIO_ISO_WIDE_SPECIFIERS”的不匹配项: 值“1”不匹配值“0”(MainWindow.obj 中) Heart G: 08_Practice 05_PracticeCPP20200713_MathGL-Qt-openCVHeartHeartmgl-qt5-static.lib(mocs_compilation.obj) 1 解决：进入项目的属性页面，修改预处理命令（Debug和Release分别修改），如下图。
That's correct, I'm surprised that setting _CRT_STDIO_ISO_WIDE_SPECIFIERS was there in RD2020 too.
I was wondering why didn't you encounter this earlier. :thinking_face:
Anyway the reason for this whole rigmarole is Windows adopted Unicode prior than C standard
Format Windows classic C standard
%s printf char* char* ⇐
%s wprintf wchar_t* char*
%S printf wchar_t* N/A
%S wprintf char* N/A
%hs printf char* char* ⇐
%hs wprintf char* char* ⇐
%ls printf wchar_t* wchar_t* ⇐
%ls wprintf wchar_t* wchar_t* ⇐
%ws printf wchar_t* N/A
%ws wprintf wchar_t* N/A
<= : These rows where the C standard agrees with the Windows classic format.
The Windows classic format came first, so the question is whether the C standard chose to align with the Windows classic format, rather than vice versa.
Defining _CRT_STDIO_ISO_WIDE_SPECIFIERS works as of Visual Studio 2019 and enables C99-conforming format specifiers.
As per my blog you stated, this was introduced in Visual Studio 2015 and was initially intended to be the new default, but that idea was subsequently abandoned.
Short answer : Don't use it.arx里面的_CRT_STDIO_ISO_WIDE_SPECIFIERS继承自这个 rxsdk_common.props
