VS2019和_NO_CRT_STDIO_INLINE，这个怪人怎么解释？

Question

请检查下面我的短代码。

pwrapper.h

#include <stdio.h>
#include <stdarg.h>

extern"C" int mm_printfA(const char *fmt, ...);
extern"C" int mm_printfW(const wchar_t *fmt, ...);

pwrapper.cpp

#include "pwrapper.h"

int mm_printfA(const char *fmt, ...)
{
    va_list args;
    va_start(args, fmt);

    int ret = vprintf(fmt, args);

    va_end(args);
    return ret;
}

int mm_printfW(const wchar_t *fmt, ...)
{
    va_list args;
    va_start(args, fmt);
    
    int ret = vwprintf(fmt, args);
    
    va_end(args);
    return ret;
}

main.cpp

#include "pwrapper.h"

// cl /MT /D _NO_CRT_STDIO_INLINE main.cpp pwrapper.cpp

void main()
{
    mm_printfA("What is %d?\n", 123);
}

#if 0
void usedull()
{
    vprintf(NULL, NULL);
    vwprintf(NULL, NULL);
}
#endif

由于某种原因，我需要使用 _NO_CRT_STDIO_INLINE 编译它，如下所示：

cl /MT /D _NO_CRT_STDIO_INLINE main.cpp pwrapper.cpp

但是链接阶段失败，提示无法解析的外部符号 vwprintf 和 vprintf 。

我发现的一个非常奇怪的解决方法是：启用usedull()函数体——尽管永远不会被调用，并且通过链接pwrapper.lib，使用下面的 bb.bat：

@setlocal EnableDelayedExpansion
@set CFLAGS=/D _NO_CRT_STDIO_INLINE

cl /nologo /c /MT %CFLAGS% pwrapper.cpp
@if errorlevel 1 exit /b 4

lib /nologo  /out:pwrapper.lib pwrapper.obj
@if errorlevel 1 exit /b 4

cl /nologo /c /MT  main.cpp
@if errorlevel 1 exit /b 4

link /nologo main.obj pwrapper.lib
@if errorlevel 1 exit /b 4

嗯，这确实有效，但为什么呢？

这不是一个令人愉快的解决方法，因为每个 exe 项目都需要包含一个“无用的”usedull() 函数。那么，有没有更好的办法呢？

我真的不知道为什么这个解决方法有效，非常欢迎对其进行解释。

==== 一些澄清 ====

我原来的帖子中有两个 main.cpp 。让我分别命名它们以供以后参考，以防有人愿意回答这个奇怪的问题。

• main.0.cpp 指的是没有 usedull() 的那个。
• main.1.cpp 指的是带有usedul() 的那个。

在这个问题中，我将 VC++ 标头和库用于应用程序（不适用于内核），并且

• 编译 main.0.cpp 和 main.1.cpp 而不使用 _NO_CRT_STDIO_INLINE。
• 我总是用 _NO_CRT_STDIO_INLINE 编译 pwrapper.cpp。

在此问题中，让 pwrapper.obj 通过 pwrapper.lib 是否会产生相同的结果。

Answer 1

简而言之：

• 使用 -D _NO_CRT_STDIO_INLINE 编译 pwrapper.cpp 告诉编译器您将提供您自己的 vprintf 和 vwprintf 实现 在链接时，并
• 编译 main.cpp 没有 -D _NO_CRT_STDIO_INLINE告诉编译器包含 vprintf 和 vwprintf 的实现，它们在链接时使用，以满足来自 usedull 和 mm_printfA< 的引用/code>/mm_printfW

因此，这个特定的组合可以在链接时解析所有未定义的符号。不过，请参阅下文了解更多讨论。

讨论

在 stdio.h 中，vprintf（我将重点讨论它，但 vwprintf 以相同的方式配置）定义如下：

_Check_return_opt_
_CRT_STDIO_INLINE int __CRTDECL vprintf(
    _In_z_ _Printf_format_string_ char const* const _Format,
                                  va_list           _ArgList
    )
#if defined _NO_CRT_STDIO_INLINE
;
#else
{
    return _vfprintf_l(stdout, _Format, NULL, _ArgList);
}
#endif

请注意，

• 如果定义了_NO_CRT_STDIO_INLINE，则这将成为前向声明，
• 而如果未定义，则完整的正文将包含在包含翻译单元。

另外，在corecrt_stdio_config.h中是否定义_NO_CRT_STDIO_INLINE决定了_CRT_STDIO_INLINE的值；如果已定义，则_CRT_STDIO_INLINE定义为空，否则定义为__inline。

将这些放在一起，

• 如果未定义 _NO_CRT_STDIO_INLINE，这些函数将成为 内联扩展，
• 否则该函数的单独实现将需要在链接时提供。

默认编译（无 /O1、/O2、无 _NO_CRT_STDIO_INLINE）

以上适用于您正在使用的特定编译和链接调用，就像没有优化后，编译器将简单地将函数体包含在 main.1.obj 的编译中。您可以使用 < 查看此内容代码>dumpbin;运行 dumpbin -symbols main.1.obj | find "| vprintf" 打印：

01D 00000000 SECT8  notype ()    External     | vprintf

显示 main.1.obj 提供 vprintf 作为外部可用符号。

检查pwrapper.obj，我们得到：

00A 00000000 UNDEF  notype ()    External     | vprintf

显示vprintf在此目标文件中未定义，需要在链接时提供。

内联扩展的优化

但是，如果我们更改 内联扩展的优化选项，我们得到不同的结果。即使使用第一级优化（-Ob1，包含在 -O1 和 -O2 中），如下所示：

cl -c -Ob1 main.1.cpp

使编译器合并主体将vprintf直接转化为usedull，并去掉vprintf的单独实现，可以使用dumpbin来确认。因此，正如您现在所期望的那样，尝试将 main.1.obj 和 pwrapper.obj 链接在一起将再次给出您原来的错误：

pwrapper.obj : error LNK2019: unresolved external symbol vwprintf referenced in function mm_printfW
pwrapper.obj : error LNK2019: unresolved external symbol vprintf referenced in function mm_printfA
main.exe : fatal error LNK1120: 2 unresolved externals

多个实现？

因此，接下来很明显，使用 -D _NO_CRT_STDIO_INLINE 编译这两个文件将会失败，因为不会实现相关方法。如果编译两者时都没有这个定义怎么办？

如果我们检查目标文件，就会发现两者都定义了 vprintf:

01D 00000000 SECT8  notype ()    External     | vprintf

和: 的

01A 00000000 SECT7  notype ()    External     | vprintf

符号，在正常情况下，这两个符号都会由于 符号的多个定义和违反一个定义规则。然而，当执行内联扩展时，编译器和链接器会为你提供支持。根据 2：

编译器可以将其创建为多个翻译单元中的可调用函数，而不是扩展头文件中定义的内联函数。编译器标记链接器生成的函数，以防止违反单一定义规则 (ODR)。