• 单击<T>图标以展开/折叠模板栏。
• 单击铅笔图标或双击模板栏以打开编辑窗口。

• 您的程序使用新的MSVC编译器开关编译：/ JMC。 默认情况下，JMC在所有调试配置中都是MSBuild项目，因此请确保在15.8 Preview 3或更高版本的最新MSVC编译器重新编译项目。
• 调试器加载包含用户代码的二进制文件的PDB。
• 在工具>选项>调试>常规>启用我的代码（默认设置）中启用了JMC。

• 修改％VSInstallDir％\ Common7 \ Packages \ Debugger \ Visualizers \ default.natjmc中的中央列表或
• 在％USERPROFILE％\ Documents \ Visual Studio 2017 \ Visualizers文件夹下创建任意数量的用户特定的.natjmc文件

1. C / C ++附加包含目录 （/ I）应包含共享的stdafx.h目录
2. C / C ++预编译头文件输出文件（/ Fp）应设置为共享pch文件（由SharedPCH项目生成）
3. 如果您的项目使用/ Zi或/ ZI编译（请参阅最后有关这些开关的更多信息），使用共享pch的项目需要将共享pch项目生成的.pdb和.idb文件复制到其特定位置以便 最终的pdb文件包含pch符号。

概述

怎么获取它？

• 访问GitHub上的 vcpkg并阅读README.md中的介绍
• 我们创建了一个新的Hana分支并将vcpkg指向了它
• 在你构建vcpkg后，执行下面的命令来安装Hana:
  • vcpkg.exe install boost-hana
  • 在Windows上安装Boost的期间，您将看到此免责声明：“当前的MSVC版本无法编译Boost hana。 请使用来自boost 1.67的分支，它上面有替代的变通方案。“

背景

代码变通方案

• MSVC特定的代码变通方案有70处: 27处在库文件本身，20处在测试用例，23处在示例。
• 这些变通方案都在独特的宏定义下，前缀为“BOOST_HANA_WORKAROUND_MSVC_”，并且每个问题都有来自我们内部数据库特定的bug ID。更多详细信息见这里。
• 下面是一些示例：

编译bug

• VS2017 15.7 update里面还有25个活跃的bug。
• 我们计划在VS2017 15.9 update中修复它们。

下一步…

• 在接下来的VS2017 update中，我们将完全修复阻塞Hana库的上游版本的剩余MSVC bug。 在我们修复错误时，我们也将逐步更新相应的代码变通方案。
• 我们将继续提供有关我们进展的最新状态。
• 我们将确保在vcpkg中依赖此库的用户不会受到我们工作的影响。
• Range-v3的进展如何？
  • 同样，我们正在跟踪编译器中的所有Range-v3 bug，并计划在接下来的Visual Studio 2017update中修复它们。

[原文发表地址] MSVC Preprocessor Progress towards Conformance [原文发表时间] 2018/07/06

为什么重写编译器预处理程序

 

最近我们发布了一篇关于C++标准完成度的一篇博客。 博客中提到， MSVC预处理程序正在进行大改动. 这样做的目的旨在提高编译器的语言标准， 解决一些因框架设计导致修复困难的一些久远的bug， 并提高可用性与诊断性。 除此之外， C++标准在某些预处理行为上并没有指定定义， 而且我们的传统行为与其他主要编译器有所不同。在这种情况下， 我们尽可能亲和当前的体系结构并使交互平台的一些库更加方便的支持MSVC。

 

如果你使用了一个依赖MSVC预处理程序的非标准传统行为的库， 你大可不用担心兼容性。更新后的预处理程序工作在/experimental:preprocessor开关下, 当完全实现时它将会转为/permissive-模式下一个含有/Zc:的默认开启开关。

 

我如何去使用

 

维护传统预处理程序的行为并继续作为编译器的默认行为。 从VS2017 Preview 3 release开启命令提示框， 使用/experimental:preprocessor选项开启标准化的预处理程序。

 

我们已经介绍了一个新的预定义宏"_MSVC_TRADITIONAL", 它可以用来标识正在被使用的传统预处理程序。这个宏不需要任何条件， 只依赖于正在使用的预处理程序。 宏返回1代表传统预处理程序， 0代表使用新的标准化的体验版预处理程序.

 

#if defined(_MSVC_TRADITIONAL) && _MSVC_TRADITIONAL

// Logic using the traditional preprocessor

#else

// Logic using cross-platform compatible preprocessor

#endif

新的变动

 

第一个发布的实验预处理程序主要致力完成对C++标准支持相关的宏，使MSVC编译器可以最大化支持各种最新库。由于使用已更新的预处理程序，在测试实际产品项目中出现了一些不兼容，我们需要进行重新修改， 下面列出一些常见的修改方案.

行为1  宏注释

传统的预处理程序基于字符串缓冲区而不是预处理单词。 下面的代码通过宏注释的技巧将不会在更新后的标准化预处理程序中工作.

#if DISAPPEAR

#define DISAPPEARING_TYPE /##/

#else

#define DISAPPEARING_TYPE int

#endif

//当DISAPPEARING_TYPE变成注释时myVal会被注释掉

//为了符合标准，使用//将随后的代码包含// #if /#endif

DISAPPEARING_TYPE myVal;

行为2 [L#val]

传统的预处理程序将字符串前缀的合并不正确的处理为#操作符

 #define DEBUG_INFO(val) L”debug prefix:” L#val

//                                       ^

//                                       this prefix

这个例子中L前缀没有必要， 因为临近的字符串字面值在宏展开后总是会合并. 向后兼容的修复是改变宏定义为

#define DEBUG_INFO(val) L”debug prefix:” #val

//                                       ^

//                                       no prefix

这个问题也出现在在字符化参数转换为宽字符串的转换宏上.

//传统的预处理程序创建一个单独的宽字符串字面值词法 #define STRING(str) L#str // 潜在的修复: // 使用L""和#str字符串连接符 // 它可以正常工作，因为临近字符串字面值在宏展开后合并 #define STRING1(str) L””#str // 在#str增一个前缀通过额外的宏展开式形成字符串 #define WIDE(str) L##str #define STRING2(str) WIDE(#str) // 使用多个#操作符合并单元 // ##，#操作符的顺序在所有编译器都是未指定的 // 在这个例子中检查##前的#操作符 #define STRING3(str) L## #str

行为3 无效的##警告

当##操作符无法形成一个单独的有效的预处理单元时， 即为未定义行为。传统的预处理程序无法继续合并标记。新的预处理程序将会与其他主要编译器行为保持一致并给出诊断.

//##是不必要的， 并不会成为一个单独的预处理语法单元 #define ADD_STD(x) std::##x //声明一个std::string对象 ADD_STD(string) s;

行为4 省略变长宏中的逗号

考虑下面的例子 #define FUNC2(a, …) func(a , ## __VA_ARGS__) int main() { // 变长参数在被调用的宏中丢弃The variadic argument is missing in the macro being evoked // 逗号将会移除并替换为Comma will be removed and replaced with: // func(1) FUNC2(1); // 变长参数为空，但不会丢弃， 注意参数列表中的逗号。 当宏被替换时逗号不会移除 // func(1, ) FUNC2(1, ); }

在即将到来的C++2a标准中， 这个问题通过添加__VA_OPT_解决， 这个特性暂时还没有实施.

行为5 宏参数未解包

在传统预处理程序中， 如果一个宏转发另一个宏依赖的参数， 这时参数被替换时不会解包。 通常这种优化会被忽视， 但是他可以导致不寻常的行为

// 在first参数和剩余参数外创建一个字符串 #define TWO_STRINGS( first, … ) #first, #__VA_ARGS__ #define A( … ) TWO_STRINGS(__VA_ARGS__) const char* c[2] = { A(1, 2) }; // 标准的预处理程序导致: // const char c[2] = { “1”, “2” }; // 传统的预处理程序导致所有的参数都在第一个字符串里 // const char c[2] = { “1, 2”, };

当展开A()时， 传统预处理程序转发所有__VA_ARGS_中打包的参数到TWO_STRINGS的第一个参数， 它使TWO_STRING的变长参数为空. #first变为"1，2" 而不是仅仅只是"1".如果仔细跟踪， 你可能好奇#_VA_ARGS_在传统预处理程序中的结果是什么； 如果变长参数为空它的值为空字符串字面值"".由于另外一个问题， 空字符串字面值没有生成.

行为6 重新扫描宏里面的替换列表

在宏被替换后， 影响的标识将会为需要被替换的附加宏标识符重新扫描。 下面的代码里，传统预处理程序在做重新扫描时使用的算法并不符合语言标准.

#define CAT(a,b) a ## b #define ECHO(…) __VA_ARGS__ // IMPL1 和 IMPL2 为实现的细节 #define IMPL1(prefix,value) do_thing_one( prefix, value) #define IMPL2(prefix,value) do_thing_two( prefix, value) // 宏将会根据Macro_switch的值选择相应的展开方式 #define DO_THING(macro_switch, b) CAT(IMPL, macro_switch) ECHO(( “Hello”, b)) DO_THING(1, “World”); // 传统的预处理程序 // do_thing_one( “Hello”, “World”); // 标准化的预处理程序 // IMPL1 ( “Hello”,”World”);

虽然这个例子有些刻意,但是我们针对真实产品代码测试预处理程序时遇到几次这样的问题. 我们分解DO_THING的展开式来看一下发生了什么.

DO_THING(1, “World”)— > CAT(IMPL, 1) ECHO((“Hello”, “World”))

然后CAT被展开为

CAT(IMPL, 1)– > IMPL ## 1 — > IMPL1

将单词变为下面的状态

IMPL1 ECHO((“Hello”, “World”))

预处理程序发现了函数式宏标识符IMPL1, 但是它的后面没有跟有一个"("， 所以不考虑函数式宏调用. 预处理程序移动到下面的单词并找到被调用的函数式宏ECHO

ECHO((“Hello”, “World”))– > (“Hello”, “World”)

IMPL1永远不会再考虑展开， 所以展开的结果为

IMPL1(“Hello”, “World”);

这个宏也可以通过增加一个间接层使传统预处理程序和标准预处理程序的展开方式一致.

#define CAT(a,b) a##b #define ECHO(…) __VA_ARGS__ // IMPL1 和 IMPL2 为宏的实现细节 #define IMPL1(prefix,value) do_thing_one( prefix, value) #define IMPL2(prefix,value) do_thing_two( prefix, value) #define CALL(macroName, args) macroName args #define DO_THING_FIXED(a,b) CALL( CAT(IMPL, a), ECHO(( “Hello”,b))) DO_THING_FIXED(1, “World”); // 宏展开为: // do_thing_one( “Hello”, “World”);

后续

预处理程序重写还没有完成;我们会在体验模式下进行修改， 并修复早期使用过程中出现的bug.

• 一些预处理指令将会与传统行为不一样
• 支持_Pragma
• C++20特性
• 进一步提升诊断能力
• 使用新的编译选项/E /P来控制输出
• 阻碍Boost的bug
  • 预处理常量表达式当中的逻辑操作符在新的预处理程序中还没有完全实现， 所以在#if指令上逻辑操作符会回退到传统的预处理程序行为。 当不匹配传统预处理的宏展开时， 回退行为较为明显, 在生成boost预处理程序插槽时也会出现这种情况.

结语

欢迎大家下载VS2017 15.8预览版并尝试使用所有实验性的新特性. 和往常一样， 我们欢迎你们的反馈。可以通过下面的留言或者电邮(visualcpp@microsoft.com). 如果你遇到其他VS2017 MSVC编译器的问题， 请通过Help > Report A Problem in the product 或者Developer Community 告诉我们. 通过USERVOICE可以让我们了解你的建议， 你也可以通过Twitter VISUAL C 与Fackbook msftvisualCpp 找到我们.

什么是代码分析规则集？

• 首先，我们需要确定一组将检测未初始化的变量和内存的规则。 对于这个例子，我们选择了两条可以帮助我们的规则，C6001和C26494。
• 现在需要创建一个规则集文件，其中包含您选择的一组规则。 我们可以在如上所示的Visual Studio中执行此操作，或者我们可以通过编写简单的XML来手动创建规则集。
• 现在我们有一个如下所示的规则集文件，我们已将其保存为UninitVariable.ruleset。
• 对于这个例子，我们的测试文件如下所示。 我们将其命名为test.cpp。
• 我们运行没有任何配置选项的代码分析并观察以下警告:

  E:\test>cl.exe /c test.cpp /analyze:plugin EspXEngine.dll

  Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26329 for x86

  Copyright (C) Microsoft Corporation.  All rights reserved.

  test.cpp

  e:\test\test.cpp(8) : warning C6001: Using uninitialized memory 'i'.: Lines: 3, 4, 8

  e:\test\test.cpp(3) : warning C26494: Variable 'i' is uninitialized. Always initialize an object (type.5).

  e:\test\test.cpp(1) : warning C26497: The function 'f' could be marked constexpr if compile-time evaluation is desired (f.4).

  e:\test\test.cpp(1) : warning C26440: Function 'f' can be declared 'noexcept' (f.6).

•  接下来，我们传递额外的编译器选项来指定我们的自定义规则集来识别未初始化的变量：/ analyze：ruleset UninitVariable.ruleset。

E:\test>cl.exe /c test.cpp /analyze:plugin EspXEngine.dll /analyze:ruleset UninitVariable.ruleset

Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26329 for x86

Copyright (C) Microsoft Corporation.  All rights reserved.

test.cpp

e:\test\test.cpp(8) : warning C6001: Using uninitialized memory 'i'.: Lines: 3, 4, 8

e:\test\test.cpp(3) : warning C26494: Variable 'i' is uninitialized. Always initialize an object (type.5).