C++开发团队致力于使你的 C++ 编码体验尽可能安全。我们正在添加更丰富的代码安全检查，并解决 C++ 开发社里反馈的各种高优先级问题。感谢你与我们互动，并就过去的版本和早期预览版向我们提供了很好的反馈，从而达到这一点。以下是我们对代码分析工具所做的改进的详细概述。

对现有检查的改进

我们改进了许多检查，以发现更多错误并发出更少的误报。本节包含我们在过去几个月中所做的工作的一些亮点。

对空 std::optionals 的展开

C26830 的旧版本检查 std::optional 的安全展开，不支持 operator== free 函数，并为以下代码产生了 C26380 误报：

>> 请移步至 topomel.com 查看图片 <<

在我们的改进之后，分析器不再对上面的代码发出警告。此添加还有助于在意外反转条件时发现更多问题：

>> 请移步至 topomel.com 查看图片 <<

我们放宽了 C26829 和 C26830，以便在潜在空 std::optional 上调用 value 方法时不发出警告。在空的可选上调用值将引发异常，一些用户更喜欢捕获该异常，而不是预先检查空性。当此异常不可接受时，我们引入了 C26859 和 C26860，它们强制显式 null 检查，保证不会引发异常。

支持有条件的移动

在某些情况下，STL 中的某些 API 会使用参数，但在其他情况下保持不变。以前，移动后使用检查假定这些选定的 API 将始终使用该参数。我们改进了检查，以更好地了解 STL 中的一些常用 API，并避免发出误报。例如，以下代码片段将不再触发任何警告：

>> 请移步至 topomel.com 查看图片 <<

在此代码片段中，当返回对的第二个元素为 false 时，try_emplace不会使用 val。在这种情况下，使用 val 是安全的。

其他改进

我们还对其他现有检查进行了许多较小的改进，包括：
> 对生存期分析的改进
> 修复了 C26440 中的误报
> 修复了 C26481 中的一些遗漏警告
> 修复了 C26813 中的一些误报

对代码分析引擎的改进

更好地建模 std::pair 和 std::swap
我们的引擎单独分析每个功能。因此，分析仪并不总是具有有关其他功能的必要信息来推断某些事实。进行函数局部分析是一个深思熟虑的设计决策，以确保我们的检查具有良好的性能和可扩展性。为了减少精度损失，我们经常将显式建模添加到广泛使用的构造（如 pair）、依赖类型信息（如 gsl::not_null）或注释（如 SAL）。请考虑以下代码：

>> 请移步至 topomel.com 查看图片 <<

由于分析器不研究 std::make_pair 的定义，因此它以前不了解此函数会将其第二个参数存储到返回对象的第二个字段中。因此，当取消引用 p 时，永远不会发出高置信度警告。从 17.6 开始，我们添加了 std::p air 及其相关方法的显式建模，以便分析器能够捕获更多错误（如上例所示），并发出更少的误报，同时保持局部静态分析。
std::swap 函数也得到了类似的处理。我们将在下面的代码片段中正确诊断问题：

>> 请移步至 topomel.com 查看图片 <<

更好地支持抑制属性

以前 [[gsl::suppress]] 不适用于声明。此问题现已修复，因此以下代码按预期工作：

>> 请移步至 topomel.com 查看图片 <<

其他问题修复

> 更好地支持 if constexpr
> 修复了循环建模问题
> 更精确地建模临时对象
> 引擎现在知道标准抛出运算符 new 不会返回空指针
> 更好的初始值设定项表达式建模
> 使某些警告的来源位置更加精确

总结

现代 C++ 越来越复杂的语法催生了各种语法检查器，它的存在，对于新手来说，可以很快找到代码中”不那么好的地方。
但是如果希望晋升为高手，则需要深刻理解分析器给出的提示背后的原因。

最后

Microsoft Visual C++团队的博客是我非常喜欢的博客之一，里面有很多关于Visual C++的知识和最新开发进展。大浪淘沙，如果你对Visual C++这门古老的技术还是那么感兴趣，则可以经常去他们那(或者我这)逛逛。
本文来自：《Code Analysis Improvements in Visual Studio 17.6》