C 运行时 (CRT) 和 C++ 标准库 (STL) .lib 文件

  • 项目

本文列出了在开发应用程序时可以针对其进行链接的 Microsoft C 运行时库 .lib 文件及其关联的编译器选项和预处理器指令。

若要了解如何部署为应用程序提供支持所需的 C 运行时文件，请参阅重新分发 Visual C++ 文件。

如果要查找 C 运行时库的 API 参考，请参阅 C 运行时库参考。

注意

Microsoft 对 C++ 标准库的实现通常称为 STL 或标准模板库。 尽管 C++ 标准库是 ISO 14882 中定义的库的正式名称，但由于搜索引擎中常用“STL”和“标准模板库”，因此我们偶尔使用这些名称，以便更轻松地查找文档。

根据历史记录，“STL”最初是指 Alexander Stepanov 编写的标准模板库。 该库的某些部分在 C++ 标准库中进行了标准化。 标准库还包含 ISO C 运行时库、Boost 库的一部分和其他功能。 有时，“STL”是指根据 Stepanov 的 STL 改编的 C++ 标准库的容器和算法部分。 在本文档中，标准模板库 (STL) 是指整个 C++ 标准库。

C 运行时 .lib 文件

ISO C 标准库是 C++ 标准库的一部分。 实现 CRT 的 Visual C++ 库支持用于 .NET 开发的本机代码开发以及本机和托管混合代码。 所有版本的 CRT 都支持多线程开发。 大多数的库都支持通过静态链接将库直接链接到代码中，或通过动态链接让代码使用常用 DLL 文件。

在 Visual Studio 2015 中，CRT 已重构为新的二进制文件。 通用 CRT (UCRT) 包含通过标准 C99 CRT 库导出的函数和全局函数。 UCRT 现为 Windows 组件，作为 Windows 10 及更高版本的一部分提供。 静态库、DLL 导入库和 UCRT 的头文件现在 Windows SDK 中提供。 安装 Visual C++ 时，Visual Studio 安装程序将安装使用 UCRT 所需 Windows SDK 的子集。 可以在 Visual Studio 2015 及更高版本支持的任何 Windows 版本上使用 UCRT。 对于 Windows 10 或更高版本以外的受支持的 Windows 版本，可以使用 vcredist 重新分发它。 有关详细信息，请参阅重新分发 Visual C++ 文件。

下表列出了实现 UCRT 的库。

库 关联的 DLL 特征 选项 预处理器指令
libucrt.lib 无 将 UCRT 静态链接到你的代码。 /MT _MT
libucrtd.lib 无 用于静态链接的 UCRT 调试版本。 不可再发行。 /MTd _DEBUG，_MT
ucrt.lib ucrtbase.dll UCRT 的 DLL 导入库。 /MD _MT，_DLL
ucrtd.lib ucrtbased.dll UCRT 调试版本的 DLL 导入库。 不可再发行。 /MDd _DEBUG, _MT, _DLL

vcruntime 库包含 Visual C++ CRT 实现特定的代码：异常处理和调试支持、运行时检查和类型信息、实现的详细信息和某些扩展的库函数。 vcruntime 库版本需要与所使用的编译器版本匹配。

此表列出了实现 vcruntime 库的库。

Library 关联的 DLL 特征 选项 预处理器指令
libvcruntime.lib 无 静态链接到你的代码。 /MT _MT
libvcruntimed.lib 无 用于静态链接的调试版本。 不可再发行。 /MTd _MT，_DEBUG
vcruntime.lib vcruntime<version>.dll vcruntime 的 DLL 导入库。 /MD _MT，_DLL
vcruntimed.lib vcruntime<version>d.dll 调试 vcruntime 的 DLL 导入库。 不可再发行。 /MDd _DEBUG, _MT, _DLL

注意

进行 UCRT 重构时，并发运行时函数会移到已添加到 C++ 可再发行包中的 concrt140.dll。 此 DLL 是 C++ 并行容器和算法（如 concurrency::parallel_for）所必需的。 此外，C++ 标准库需要 Windows XP 版的此 DLL 来支持同步基元，因为 Windows XP 不具有条件变量。

初始化 CRT 的代码是几个库中的一个，根据 CRT 库是采用静态或动态链接还是本机、托管或混合代码而定。 此代码处理 CRT 启动、内部逐线程数据初始化和终止。 它特定于所用编译器的版本。 此库始终采用动态链接，即使使用动态链接的 UCRT 也是如此。

此表列出了实现 CRT 初始化和终止的库。

库 特征 选项 预处理器指令
libcmt.lib 将本机 CRT 启动静态链接到你的代码。 /MT _MT
libcmtd.lib 静态链接本机 CRT 启动的调试版本。 不可再发行。 /MTd _DEBUG，_MT
msvcrt.lib 与 DLL UCRT 和 vcruntime 一起使用的本机 CRT 启动的静态库。 /MD _MT，_DLL
msvcrtd.lib 与 DLL UCRT 和 vcruntime 一起使用的本机 CRT 启动调试版本的静态库。 不可再发行。 /MDd _DEBUG, _MT, _DLL
msvcmrt.lib 与 DLL UCRT 和 vcruntime 一起使用的本机和托管混合 CRT 启动的静态库。 /clr
msvcmrtd.lib 与 DLL UCRT 和 vcruntime 一起使用的本机和托管混合 CRT 启动调试版本的静态库。 不可再发行。 /clr
msvcurt.lib 纯托管 CRT 的已弃用静态库。 /clr:pure
msvcurtd.lib 纯托管 CRT 调试版本的已弃用静态库。 不可再发行。 /clr:pure

如果从没有编译器选项（可指定 C ++运行时库）的命令行链接程序，则链接器将使用静态链接的 CRT 库：libcmt.lib、libvcruntime.lib 和 libucrt.lib。

使用静态链接的 CRT 意味着由 C 运行时库保存的任何状态信息对于 CRT 的该实例而言是本地的。 例如，如果在使用静态链接的 CRT 时使用 strtok，则 strtok 分析器的位置将与链接到另一个静态 CRT 实例的同一进程（但在不同的 DLL 或 EXE 中）的代码中使用的 strtok 状态无关。 相反，动态链接的 CRT 可共享动态链接到 CRT 的进程中的所有代码的状态。 如果使用这些函数的更安全的新版本，则这一问题不适用；例如，strtok_s 不存在此问题。

由于通过链接到静态 CRT 生成的 DLL 具有自己的 CRT 状态，因此不建议静态链接到 DLL 中的 CRT，除非理解并需要这一后果。 例如，如果在加载 DLL（链接到其自己的静态 CRT）的可执行文件中调用 _set_se_translator，则转换器将不会捕获由 DLL 中的代码生成的任何硬件异常，但会捕获由主可执行文件中的代码生成的硬件异常。

如果使用 /clr 编译器开关，则将通过静态库 msvcmrt.lib 链接代码。 静态库将提供托管的代码和本机 CRT 之间的代理。 你无法使用静态链接的 CRT（/MT 或 /MTd 选项）和 /clr。 请改用动态链接的库（/MD 或 /MDd）。 纯托管的 CRT 库在 Visual Studio 2015 中已弃用并在 Visual Studio 2017 中不受支持。

若要详细了解如何将 CRT 与 /clr 配合使用，请参阅混合（原生和托管）程序集。

若要生成你的应用程序的调试版本，则必须定义 _DEBUG 标志，并且该应用程序必须与其中一个调试版本的库链接。 有关使用调试版本的库文件的详细信息，请参阅 CRT 调试技术。

此版本的 CRT 不完全符合 C99 标准。 在 Visual Studio 2019 版本 16.8 之前的版本中，不支持 <tgmath.h> 头文件。 在所有版本中，不支持 CX_LIMITED_RANGE 和 FP_CONTRACT pragma 宏。 某些元素（如标准 IO 函数中参数说明符的含义）默认采用旧的解释。 可以使用 /Zc 编译器一致性选项并指定链接器选项来控制库一致性的某些方面。

C++ 标准库 (STL) .lib 文件

C++ 标准库 特征 选项 预处理器指令
libcpmt.lib 多线程, 静态链接 /MT _MT
msvcprt.lib 多线程动态链接（msvcp<version>.dll 的导入库） /MD _MT，_DLL
libcpmtd.lib 多线程, 静态链接 /MTd _DEBUG，_MT
msvcprtd.lib 多线程动态链接（msvcp<version>d.dll 的导入库） /MDd _DEBUG, _MT, _DLL

当构建项目的发行版时，默认情况下，将链接基本 C 运行时库（libcmt.lib、msvcmrt.lib、msvcrt.lib）之一，具体取决于你选择的编译器选项（多线程、DLL、/clr）。 如果在代码中包含 C++ 标准库头文件之一，则将在编译时通过 Visual C++ 自动链接 C++ 标准库。 例如：

#include <ios>

对于二进制兼容性，可通过单个导入库指定多个 DLL 文件。 版本更新可能会引入点库，点库是引入新的库功能的 单独的 Dll。 例如，Visual Studio 2017 版 15.6 引入了 msvcp140_1.dll 以支持更多标准库功能，而不会破坏由 msvcp140.dll 支持的应用程序二进制接口 (ABI)。 适用于 Visual Studio 2017 版本 15.6 的工具集中包含的 msvcprt.lib 导入库支持两个 DLL，而此版本的 vcredist 安装两个 DLL。 传送后，点库具有固定 ABI，且不会在以后的点库中包含依赖项。

如果应用程序使用多个 CRT 版本，将存在什么问题？

每个可执行映像（EXE 或 DLL）可以具有其自己静态链接的 CRT，或可以动态链接到 CRT。 静态包括在某个映像中或某个映像动态加载的 CRT 版本取决于构建 该 CRT 时采用的工具和库。 单个进程可能会加载多个 EXE 和 DLL 映像，每个都有其自己的 CRT。 每个 CRT 可能使用不同的分配器，可能具有不同的内部结构布局，可能使用不同的存储排列方式。 这意味着，分配的内存、CRT 资源或跨 DLL 边界传递的类可能会导致内存管理、内部静态使用情况或布局解释方面的问题。 例如，如果在一个 DLL 中分配类，但将其传递给另一个 DLL 或由另一个 DLL 删除，那么使用了哪个 CRT 释放器？ 导致的错误程度可以从微小到立即致命，因此建议不要直接传输此类资源。

你可以使用应用程序二进制接口 (ABI) 技术避免这些问题，因为这些技术被设计成稳定且版本可控。 设计 DLL 导出接口以按值传递信息，或致力于调用方传入而非本地分配并返回给调用方的内存。 使用封送技术在可执行映像之间复制结构化数据。 本地封装资源并仅允许通过向客户端公开的句柄或函数操作。

如果进程中的所有映像全都使用相同的 CRT 动态加载版本，则也有可能避免这些问题。 若要确保所有组件都使用 CRT 的同一 DLL 版本，请使用 /MD 选项构建它们，并使用相同的编译器工具集和属性设置。

如果程序跨 DLL 边界传递某些 CRT 资源，请小心。 即使是在使用同一 CRT 版本的情况下，文件句柄、区域设置和环境变量等资源也可能会导致问题。 有关所涉及问题以及如何解决这些问题的详细信息，请参阅跨 DLL 边界传递 CRT 对象时可能的错误。

另请参阅

C 运行时库参考
重新分发 Visual C++ 文件