1. 问题缘起一个困扰C开发者的“古董”宏如果你是一名在Windows平台上使用Visual Studio进行C开发的程序员尤其是当你需要编写跨平台代码或者依赖一些根据__cplusplus宏来启用现代C特性的第三方库时很可能踩过这个坑你明明在项目属性里将“C语言标准”设置为了/std:c17、/std:c20甚至最新的/std:clatest满怀期待地在代码中打印__cplusplus的值结果终端上冷冰冰地显示着199711L。这个数字代表什么它代表的是1997年12月定稿的第一版ISO C标准也就是我们常说的C98。在2023年的今天你的编译器明明支持C20的特性但这个关键的“身份证”宏却告诉全世界你的代码还停留在上个世纪。这不仅仅是面子问题它会导致一系列实际开发障碍。比如一些优秀的开源库如Fmtlib、Spdlog的某些配置或一些头文件库会通过检查__cplusplus来判断是否启用constexpr、结构化绑定等现代特性。当这个宏“谎报军情”时这些库可能会退回到兼容模式导致你无法使用其最优、最现代的功能甚至引发编译错误。这个问题并非Visual C以下简称MSVC的新毛病而是一个历史遗留的“兼容性”选择。微软为了确保那些依赖于__cplusplus旧值的老旧代码库尤其是企业内部的遗留系统在升级编译器后仍能正常编译在默认情况下选择不更新这个宏。从Visual Studio 2015到最新的2022版本这个行为一直存在。然而对于绝大多数开发现代C应用程序、库和游戏的开发者来说这个默认行为已经弊大于利。我们需要明确地告诉编译器“请告诉我真实的C标准版本。” 本文将彻底拆解这个问题的成因并提供从项目配置到代码层面的多种解决方案让你一劳永逸地解决这个顽疾。2. 核心原理为什么__cplusplus会“说谎”要解决问题首先得理解编译器在背后做了什么。__cplusplus是一个预定义宏由C标准规定其值应该是一个长整型字面量代表编译器所遵循的C标准的年份和月份。例如C11对应201103LC14对应201402LC17对应201703LC20对应202002L。MSVC作为一个商业编译器其设计目标之一是最大限度地保持向后兼容性。在Visual Studio 2017版本15.5对应MSVC工具集版本14.12之前__cplusplus宏始终被定义为199711L无论你使用了什么语言标准。这是因为当时有海量的生产代码依赖这个值来判断编译器是否“足够古老”从而启用一些特定的workaround变通方案。如果微软突然开始报告真实版本这些代码可能会错误地启用一些在新编译器下不兼容的路径导致编译失败或运行时错误这是企业级用户无法接受的。因此微软引入了一个编译器开关来控制这个宏的行为。这个开关就是/Zc:__cplusplus。这个/Zc前缀代表“一致性”conformance是MSVC一系列用于控制编译器是否严格遵循C标准行为的开关之一。当不使用/Zc:__cplusplus默认情况时编译器处于“最大兼容模式”__cplusplus被固定为199711L以保护那些陈旧的代码。当使用/Zc:__cplusplus开关时编译器进入“标准一致模式”__cplusplus宏会被正确设置为当前语言标准对应的值。这里有一个关键点仅仅在项目属性中设置“C语言标准”如/std:c17并不会自动启用/Zc:__cplusplus。这两个设置是独立的。/std选项告诉编译器前端允许使用哪些语法和库特性而/Zc:__cplusplus选项告诉编译器预处理器如何定义那个宏。你必须同时打开两者才能既享受新标准的语法又让宏反映出新标准的版本。注意除了__cplusplusMSVC还有一个自己定义的宏_MSVC_LANG。在默认情况下_MSVC_LANG会正确地反映你通过/std选项设置的语言标准版本。因此在一些仅针对MSVC的代码中你可能会看到通过检查_MSVC_LANG来判断C版本。但为了代码的跨平台兼容性在GCC和Clang中正确的宏是__cplusplus我们仍然需要解决__cplusplus的问题。3. 解决方案一通过Visual Studio IDE图形界面配置这是最直观、最推荐给大多数开发者的方法特别是当你主要工作在解决方案和项目文件中时。3.1 为单个项目配置打开项目属性在解决方案资源管理器中右键点击你的项目选择“属性”。定位配置选项在属性页中依次导航到“配置属性” - “C/C” - “语言”。启用“符合模式”找到名为“启用符合模式下的 __cplusplus”Enable __cplusplus in Conformance Mode的选项。在下拉框中将其从默认的“否”改为“是/Zc:__cplusplus”。实操心得这个选项的中文翻译非常准确它直接对应了/Zc:__cplusplus编译器开关。在英文版VS中这个选项叫“Enable __cplusplus in Conformance Mode”。确保你修改的是当前正在使用的配置如Debug/Release和平台Win32/x64。验证语言标准在同一个“语言”属性页中确认上方的“C语言标准”选项已经设置为你想要的版本例如“ISO C17 标准 (/std:c17)”。应用并重新生成点击“应用”然后“确定”。务必执行“重新生成”项目因为预处理器宏的更改不会在增量编译中生效。3.2 为多个项目或全局配置如果你有多个项目或者希望所有新项目都默认启用此设置逐个修改会很繁琐。属性表Property Sheets这是VS中管理共享配置的利器。你可以创建一个.props文件在其中设置好/Zc:__cplusplus和/std:cxx然后将这个属性表应用到多个项目上。方法是在“属性管理器”视图中可通过“视图”-“其他窗口”-“属性管理器”打开右键点击你的项目或配置选择“添加现有属性表”。全局默认设置修改全局默认设置较为复杂且不推荐因为它可能影响你不希望改变的其他项目。更安全的方式是创建一个自定义的项目模板在模板中预置这些设置。重要提示修改此设置后如果你的项目中有第三方库或旧代码片段是依赖__cplusplus为199711L来编译的那么它们可能会报错。你需要评估这些代码并对其进行更新或条件编译处理。这恰恰是启用这个开关的意义——暴露潜在的兼容性问题让你的代码库更健康。4. 解决方案二通过命令行与CMake配置对于习惯使用命令行编译或者项目构建系统基于CMake的开发者需要在不同的地方进行配置。4.1 直接使用CL.EXE命令行如果你直接调用MSVC的编译器cl.exe只需在编译命令中加入/Zc:__cplusplus选项即可。cl /EHsc /std:c17 /Zc:__cplusplus your_source.cpp你可以编写一个简单的脚本来验证// test_cppver.cpp #include iostream int main() { std::cout __cplusplus __cplusplus std::endl; #ifdef _MSVC_LANG std::cout _MSVC_LANG _MSVC_LANG std::endl; #endif return 0; }使用命令cl /EHsc /std:c17 /Zc:__cplusplus .\test_cppver.cpp编译并运行你将看到输出__cplusplus 201703L。4.2 在CMakeLists.txt中配置CMake是现代C跨平台项目的标配。为了让MSVC正确报告__cplusplus你需要在CMakeLists.txt文件中添加相应的编译选项。方法A使用target_compile_options(推荐)这是最精准的方式针对特定的目标可执行文件或库设置选项。cmake_minimum_required(VERSION 3.10) project(MyCppProject) add_executable(MyApp main.cpp) # 设置C标准为17 set_target_properties(MyApp PROPERTIES CXX_STANDARD 17 CXX_STANDARD_REQUIRED ON ) # 针对MSVC编译器添加 /Zc:__cplusplus 选项 if(MSVC) target_compile_options(MyApp PRIVATE /Zc:__cplusplus) endif()方法B使用add_compile_options这会为当前目录及所有子目录下的所有目标添加编译选项影响范围更广需谨慎使用。if(MSVC) add_compile_options(/Zc:__cplusplus) endif()方法C通过CMAKE_CXX_FLAGS变量这是更传统的方式直接修改CMake的C编译器标志变量。if(MSVC) set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /Zc:__cplusplus) endif()实操心得在CMake项目中我强烈推荐方法A。它遵循了CMake现代最佳实践将选项的作用域限定在特定目标上避免了全局设置可能带来的副作用。同时务必使用CXX_STANDARD_REQUIRED ON这告诉CMake如果编译器不支持请求的标准就报错而不是静默降级。5. 解决方案三代码层面的变通与检测在某些极端情况下你可能无法修改构建系统例如在阅读某些第三方库的源码或者在一个受限制的构建环境中。此时可以在代码头文件中进行变通处理。5.1 手动重定义宏不推荐但需了解理论上你可以在包含任何其他头文件之前强制重新定义__cplusplus宏。#undef __cplusplus // 根据 _MSVC_LANG 来定义因为 _MSVC_LANG 通常是正确的 #ifdef _MSVC_LANG #define __cplusplus _MSVC_LANG #else // 非MSVC编译器或者非常老的MSVC这里需要其他逻辑 #define __cplusplus 201703L // 假设是C17 #endif为什么强烈不推荐因为__cplusplus是一个预定义宏。在C标准中重新定义预定义宏的行为是未定义的。这意味着编译器可以做任何事情它可能接受你的定义可能忽略也可能直接报错。不同编译器、甚至同一编译器的不同版本行为都可能不一致。这为代码埋下了巨大的可移植性隐患。5.2 创建平台无关的版本检测头文件推荐更健壮的做法是不依赖单一的__cplusplus宏而是创建一个自适应的版本检测头文件。这个头文件会综合判断各种编译器特有的宏得出当前激活的C标准版本。// cpp_version_detect.hpp #pragma once // 首先尝试使用标准的 __cplusplus #if defined(__cplusplus) #define MYPROJECT_CPP_STANDARD __cplusplus #else #define MYPROJECT_CPP_STANDARD 0L #endif // 针对MSVC的特殊处理如果 _MSVC_LANG 存在且比当前的 __cplusplus 更新则采用 _MSVC_LANG // 这解决了MSVC下未启用 /Zc:__cplusplus 的问题 #if defined(_MSC_VER) defined(_MSVC_LANG) #if _MSVC_LANG MYPROJECT_CPP_STANDARD #undef MYPROJECT_CPP_STANDARD #define MYPROJECT_CPP_STANDARD _MSVC_LANG #endif #endif // 现在你可以使用 MYPROJECT_CPP_STANDARD 进行安全的版本检查 #if MYPROJECT_CPP_STANDARD 202002L #define MYPROJECT_CPP_20 1 #define MYPROJECT_CPP_17 1 #define MYPROJECT_CPP_14 1 #define MYPROJECT_CPP_11 1 #elif MYPROJECT_CPP_STANDARD 201703L #define MYPROJECT_CPP_17 1 #define MYPROJECT_CPP_14 1 #define MYPROJECT_CPP_11 1 #elif MYPROJECT_CPP_STANDARD 201402L #define MYPROJECT_CPP_14 1 #define MYPROJECT_CPP_11 1 #elif MYPROJECT_CPP_STANDARD 201103L #define MYPROJECT_CPP_11 1 #endif在你的项目源文件中包含这个头文件然后使用MYPROJECT_CPP_17这样的宏来判断特性是否可用。这种方法完全合法且可移植性极佳。许多大型开源项目如Boost内部都采用类似的检测机制。6. 深入排查常见问题与进阶场景即使按照上述步骤操作有时问题可能依然存在。以下是几个需要深入排查的点和进阶场景。6.1 检查编译器命令行编译器实际接收到的参数才是最终决定因素。在Visual Studio中你可以在“项目属性” - “C/C” - “命令行”页面底部看到“所有选项”框。这里展示了传递给cl.exe的完整命令。确保在列表中能看到/Zc:__cplusplus。如果没有说明之前的设置没有生效可能需要检查属性继承或是否有其他设置覆盖了它。6.2 预编译头文件StdAfx.h的干扰如果你的项目使用了传统的预编译头文件通过/Yc和/Yu选项需要特别注意。__cplusplus宏的值是在预处理阶段确定的。如果创建预编译头文件StdAfx.cpp编译时时没有启用/Zc:__cplusplus那么整个预编译头单元“冻结”的__cplusplus值就是199711L。之后即使你在使用该预编译头的其他源文件中启用了该选项也无法改变已经冻结的值。解决方案你必须确保生成预编译头文件的那个编译单元通常是StdAfx.cpp也在相同的、启用了/Zc:__cplusplus的配置下编译。最稳妥的方法是在项目属性中全局设置该选项然后对项目进行“清理” - “重新生成”。6.3 与/permissive-模式的关系/permissive-是MSVC的“严格一致性”模式它会启用多个标准一致性检查。在较新版本的Visual Studio如VS2019 16.8以后中当你设置“C语言标准”为/std:clatest时/permissive-模式可能会被自动启用。但需要注意的是/permissive-并不会自动包含/Zc:__cplusplus。它们是两个独立的、但目标一致提高标准符合性的选项。你应该同时启用它们以获得最佳的标准一致性。6.4 第三方库的依赖问题这是启用/Zc:__cplusplus后最可能遇到的运行时问题。你编译自己的代码没问题但在链接或运行时如果依赖的某个第三方预编译库.lib或.dll是在__cplusplus为199711L的情况下编译的而你的代码将其当作新标准版本来使用可能会导致微妙的ABI应用程序二进制接口不兼容问题比如标准库容器内部布局不同。排查与解决尽量从源码编译第三方库使用与你主项目相同的编译器和一致的设置包括/Zc:__cplusplus和/std重新编译第三方库。这是最根本的解决方法。寻找官方提供的、匹配的预编译版本一些流行的库如vcpkg中的包会提供多种配置的预编译版本。隔离兼容层如果无法重新编译考虑将与该库的交互封装在一个独立的模块中这个模块单独使用旧的、兼容的编译器设置进行编译然后通过纯C接口或谨慎设计的C接口与主程序通信。7. 最佳实践总结与配置清单经过以上分析我们可以总结出一套在Windows平台上使用MSVC进行现代C开发的最佳配置流程以确保开发环境健康、标准。统一配置入口对于Visual Studio解决方案优先使用**属性表.props**来管理/Zc:__cplusplus和/std:cxx等关键编译选项。创建一个名为ModernCpp.props的属性表应用于所有项目。核心编译选项在Debug和Release配置中确保至少设置以下两项C语言标准设置为项目所需的标准如/std:c17或/std:c20。启用符合模式下的 __cplusplus设置为“是/Zc:__cplusplus”。推荐附加选项为了获得更好的标准符合性和代码质量建议同时启用符合模式/permissive-帮助捕获不符合标准的代码。所有警告/Wall或至少/W4并将警告视为错误/WX在项目稳定后启用。构建脚本与CI/CD在CMakeLists.txt中使用if(MSVC)条件判断并通过target_compile_options为目标添加/Zc:__cplusplus。确保CI/CD流水线中的构建命令也传递了此标志。代码层面防御对于旨在跨平台或分发给他人使用的库代码考虑采用“5.2”节中的版本检测头文件方案而不是直接硬编码检查__cplusplus。这能最大程度兼容用户可能的各种编译器配置。团队规范将上述配置属性表或CMake片段纳入项目的版本控制系统如Git并写入团队的新项目开发规范文档中。新成员拉取代码后应能直接获得正确的配置避免每个人重新踩坑。我个人在带领团队进行现代C项目开发时会将一个配置好的属性表文件放在解决方案根目录并将其作为“必读”事项写入README。这看似是一个小配置但它标准化了项目的编译环境基础避免了大量因标准版本误解导致的诡异编译错误和库兼容性问题从长远看为团队节省了大量的排查时间。记住在C的世界里明确的配置远胜于隐式的约定尤其是在与编译器打交道的时候。