VS17。5预览版2Gw链接开关的标准一致性改进

　　Gw链接开关可以告诉链接器优化代码中的全局数据，从而减小最终生成的二进制文件的大小。在VisualStudio17。5预览版2中，我们新增了一个新的标志：Zc：checkGwOdr〔〕，目的是在使用Gw开关的时候改进对C标准的一致性支持。
　　在之前的版本中，当使用Gw开关的时候，某些单定义规则（ODR）冲突会被忽略，并且不会导致错误。有了这个新标志之后，如果发生这种情况的时候，VS将会报告错误。如果你正在使用Gw，则我们推荐使用Zc：checkGwOdr这个标志。默认情况下，这个标志是被关闭的。在将来的新版本VS中，我们可以改变这个默认设置。
　　如果你想了解关于ODR的解释，Gw开关，以及有关这个问题的更多信息，请继续阅读。
　　让我们来看看下面三个定义，先建立对这个问题的基本背景知识：
　　1。首先是COMDAT，简短的描述是COMDAT是可以放置数据的额外段，以使链接器能够潜在地从二进制文件中折叠出所述数据。重要的是，这些部分标有如何处理重复项的策略。有关COMDAT历史的更深入探讨，请参阅Raymond的博客文章，其中涵盖了它们的使用和历史。
　　2。接下来，Gw开关是做什么的？该开关使编译器能够将全局数据放入COMDAT中。这使我们能够优化未引用的全局变量，或通过它们的COMDAT部分合并相同的全局变量。
　　3。关于单定义规则（ODR），可以在网上找找相关的信息。
　　有了上面的背景知识，下面我们来看一个简单的例子：
　　如果不使用Gw开关，编译上面的代码会产生如下的编译错误：
　　由于我们在odr。h中定义了MyGlobal，因此我们最终在foo。obj和bar。obj中都有一个定义，导致链接器报告ODR违规。现在，如果我们使用Gw编译：
　　我们最终没有出现错误，那么发生了什么？它最终回到上面提到的COMDAT标志。查看obj的头文件，我们可以看到MyGlobal确实被放置在COMDAT中：
　　这没有显示的是这个COMODAT已被标记为PICKANY。因此，当找到多个可以合并的候选定义时，链接器会任意选择其中一个并丢弃其余定义。不过这很奇怪，当启用Gw时，此COMDAT在创建时被标记为NOMATCH。NOMATCH，顾名思义，意味着如果找到重复项，链接器应该引发错误，这正是我们想要的。那么，出了什么问题呢？
　　这里的关键是MyGlobal的定义包括零赋值。这会导致另一个优化启动。由于此全局初始化为零，我们注意到它可以移动到。bss部分。由于如果此全局数据位于。bss中，则不必存储此全局数据，因此移动COMDAT可以减小对象文件大小。不幸的是，当我们移动COMCTAT时，标志从NOMATCH重置为PICKANY，导致我们的错误。
　　从17。5预览版2开始，你现在可以使用新标志来确保不会在意外使用Gw时隐藏这些ODR违规：
　　暴露错误后，我们可以在头文件中创建全局extern，并将定义移动到其中一个cpp文件以解决问题：
　　或者，对于C17及更高版本，可以在定义上使用内联说明符（inlinespecifier）。
　　通常修复ODR违规看起来像这样，尽管并非每种情况都如此简单。如果你使用的是Gw，我们鼓励使用Zc：checkGwOdr，以防止这些冲突蔓延到你的构建中。由于这是一个标准一致性问题，我们可能会在未来的版本中更改Gw的默认行为以暗示Zc：checkGwOdr。总结
　　不知道你有什么想法，但我感觉这事儿有点按下葫芦（Gw）浮起瓢（Zc：checkGwOdr）。
　　顺便说一句，TopomelBox开发中，我压根没用过这些高级优化的劳什子玩意儿。
　　随它去吧。最后
　　MicrosoftVisualC团队的博客是我非常喜欢的博客之一，里面有很多关于VisualC的知识和最新开发进展。大浪淘沙，如果你对VisualC这门古老的技术还是那么感兴趣，则可以经常去他们那（或者我这）逛逛。
　　本文来自：《StandardsconformanceimprovementstoGwinVisualStudioversion17。5Preview2》