C++ 20 STL特点：GITHUB开发1年

我的cppcon2020演讲“C++20stl特性：GitHub上一年的开发”，现在 在YouTube上提供 . 这些幻灯片在GitHub上作为 PDF格式 原汁原味 PPTX公司 .

演讲包含完整的例子（不是片段！）几个C++ 20的特点：整数比较函数、CONTHEXPR算法、统一容器擦除、原子化ReF、和SPAN。

以下是演讲结束时的重要链接：

• 存储库： github.com/microsoft/STL
• 更改日志： github.com/microsoft/STL/wiki/Changelog
• 状态图： microsoft.github.io/STL/
• C++ 20： wg21.link/n4861

最后，在演讲结束时，我有时间回答了六个问题，但还有更多的问题。下面是这些额外的问题和我的答案：

问：为什么要挤压请求而不是合并请求？

答： 这大大简化了分支的历史，因为一个压缩的commit==一个PR。您仍然可以在GitHub上查看PR的历史。合并将创造高度非线性的历史（使得很难弄清楚什么时候事情发生了变化以及为什么发生了变化；MSVC内部git回购充满了非线性合并，因此我们在这方面有着丰富的经验。来自非压缩合并的大多数信息也会很无趣–基本上是代码评审反馈、在开发过程中修复错误等。对于非常不寻常的情况，我可以想象希望将PR排序为一系列提交，然后重新设置优先级并合并到默认分支，我们需要通过策略临时启用该分支，但一般来说，在公共关系中有这样的历史就足够了。

问：关于原子引用，当您不想支付原子惩罚时，为什么不指定轻松访问？

答： 我的理解是，放松手术仍然比普通手术要昂贵得多。例如，在MSVC的x86/x64上，原子增量是由∗u InterlockedIncrement实现的，它提供了完整的顺序一致性，即使您要求放宽；我听说这大约需要10-100个周期，而普通的增量是半个周期或更少。即使是在ARM/ARM64上，如果有用于relaxed的内部函数（“无界限”），我相信与普通逻辑相比，它们仍然意味着额外的成本。

问：您是否已经期望您的STL开源将提高STL的团队吞吐量？或者你害怕与第三方贡献者合作会带来太多的开销？

答： 好问题——这是我们在开放式采购的道路上最想/担心的事情之一。我想说的是，我们准备在短期内承担管理费用/吞吐量成本，同时希望在长期内提高吞吐量，并惊喜地发现短期成本低于预期，而且我们已经享受到了吞吐量的增长——例如，中点/lerp之所以迟迟没有出现，是因为我们没有深厚的数字专业知识，直到statementreply贡献了惊人的公关分析和解决了剩余的问题。我相信主要的吞吐量增长还将到来——我对C++ 23和更高版本的计划/梦想是，建议将基于我们的STL实现，以便一旦WG21接受该建议，PR就准备好被审查和合并。同时对libc++做出贡献的加分），这将提高标准化质量/吞吐量以及实现。

问：对于已发布的二进制文件，是否与Microsoft面向公众的符号和源服务器集成，以便调试器在调试期间拉入正确版本的源代码？

答： 这里的答案是，VS产品的构建方式和与symbol服务器的交互方式没有变化，因此一切都将继续工作。GitHub是我们进行所有开发的地方，我们通过将PRs复制到MSVC来确保repo与MS internal src/vctools/crt/GitHub树是二进制的。在那里，构建产品，将源代码打包到VS安装程序中，并将pdb上载到symbol服务器。在不久的将来，我们可能会通过GitHub CI系统构建正式的二进制文件，然后通过某种机制将它们捆绑到VS中——但我们现在还不确定如何做到这一点，这将涉及到大量的工作，以获得不明确的回报。我们应该能够通过简单地完成构建系统迁移，然后获得MS内部MSVC MSBuild系统（这么多MS！）调用我们用于GitHub的CMake/Ninja构建系统；我们已经为llvmasan支持库提供了这样的CMake调用。

问：您是否遇到过标准中的设计不实用的情况？你向委员会报告了吗？

答： 是的，这种情况经常发生。“这个设计对实现者和/或用户来说不是很好”和“这个规范不清楚/与其他实践不一致/内部不一致/违反动量守恒”之间有区别。对于前者（次优设计），我们有时会向Library Evolution工作组提及，尤其是在开发新功能时，但在工作文件中接受某个功能后，通常“为时已晚”(不一定，因为特性可以在国际标准发布之前进行修改；发生的一个地方是在C++ 20完成之前，没有收到SigZHype类型的SUN。后者（伪造规范）是常见的，我们将这些报告给库工作组（如LWG问题），这些问题通常可以快速解决。同时，我们用我们最好的判断来实现什么是可能的，什么是标准“应该说的”。

问：为什么不适用于wchar ？

答： 这是一个问题，詹斯莫雷尔谁提出的特点。我的理解是charconv是一个最小的API，其思想是它将主要用于JSON和char足够的其他API。然而，将wcharu t转换成char和back，即使是为了有限的float解析目的，也是非常不方便/缓慢的，而且转换成char的速度比L[E]WG中的任何人当时意识到的要快得多（因为Ulf Adams在这个特性被接受之后发明了Ryu和Ryu Printf！），因此，wchar 转换的开销变得更加重要。虽然charconv非常复杂，但要让它处理wchar 将是一个非常简单的问题，即模板化与字符交互的代码路径；不需要复制表和核心算法。

问：开放源代码的决定是自上而下的，还是团队必须向上努力才能说服管理层这是个好主意？

答： 一个有趣的问题，我想我可以说，这是一个自下而上的决定-马哈茂德萨利赫（我的老板，风险投资图书馆开发负责人）推动了获得批准的过程，得到了MSVC链其他成员的支持。我们必须说服我们的超级老板们，这是一个好主意，但这并不是一场战斗——这是一次有益的练习，让他们思考在公开场合工作的理由、成本/收益和后果。自上而下的战略变革无疑使这成为可能——对10年前的微软来说，开源是不可想象的，而现在我们正在不断寻找有意义的地方，包括STL和.netcore等基础组件（我们与该团队进行了交流，作为开源的一部分，以了解我们即将面临的挑战和机遇，他们非常有帮助）。

我们寻找的机会是我们可以提高整个C++社区的利益的地方，所以当程序员想到C++的未来时，他们自然会想到微软。例如，当主要的工具链及时支持高质量的功能时，所有C++程序员都受益，因此微软投入了大量的开发人员多年的努力来赶上一致性，直到MSVC常常是第一个实现新功能的点。STL是开放源码最有吸引力的机会，原因有几个：它的代码库和测试套件相对较小（绝对值很大，毕竟是标准的一半！）但比编译器或其他大型项目要小），我们已经在运送它的源代码以供查看，所以它“只是”更改许可证的问题，库的发展越来越快，而且（也许最重要的是）库往往没有深度互联，因此，在不了解和改变其他一切的情况下，添加或更改内容是可能的。现在我们有了一个开源的标准库，比如GCC的libstdc++和Clang/LLVM的libc++，我们希望以一种在所有平台上都能很好地工作的形式提出标准化的库特性会更容易。

问：学习所有最新STL特性的最佳方法是什么？有在线食谱吗？功能型风格？你的团队里有专家在写书吗？

答： 我想说最好的方法是实现它们STL维护人员没有时间写一本书，但是我们正在与微软文档团队的Tyler Whitney合作，他为我们在过去几年中实现的各种特性添加文档。cppference也是社区建立的一个很好的信息来源。我通常认为，学习一个特性的最好方法，除了实现它之外，是先在玩具示例中使用它，在一个简单干净的环境中熟悉基础知识，然后在真正的代码库中以基本的方式使用它，然后再开始高级使用。尝试在生产代码库中立即使用新功能可能会让人头痛，因为您可能无法立即看到问题是由于错误地尝试使用功能本身造成的，还是由于与代码库的交互造成的（“我知道如何使用此功能，所以这里出了什么问题–哦，这是因为它需要可复制性，但这种类型是只移动，好吧“或其他）。如果你找到更好的方法，告诉我！也可以直接阅读图书馆标准-它非常详细。缺点是，它是用一种有点奇怪的风格编写的，有时信息会“隐藏”在其他地方（例如，容器规范以一种不寻常的方式高度集中），但通常可以通过这种方式找到函数签名、基本类型要求和值先决条件。核心语言Standardese对于普通人（与非凡的编译器开发人员相比）来说要难理解得多，但我当然会这么说，因为我是一个专门研究STL的库开发人员，因为与编译器开发相比，STL很容易理解

问：这是VS2019 16.8.0预览版3.0的一部分吗？

答： 是的，我描述的所有特性都可以在今天的版本中使用。我们认为他们是在生产质量，与通常的警告，预览版本不“上线”支持的VS，这是/std:c++latest 在技术上被认为是实验性的，可能会发生变化(注意，我们可以并且已经打破了ABI/std:c++latest 特点- ABI锁定将发生在我们完成C++ 20和添加/std:c++20 为了庆祝。所以任何用/std:c++latest 确实需要用最新的工具集不断构建-但如果你想生活在C++的前沿，那不应该是个问题！

问：vNext什么时候会成为一个具体的版本？

答： 我们的计划仍然是暂时的，可能会发生变化，但是我们计划在完成C++ 20之后，在一个干净的切换中工作，即VS 2019（从VS 2015开始的“V19”版本系列）将接收所有的C++ 20特性，然后我们将做VNEXT，然后C++ 23的特性将被添加到VNEXT只-我们将继续为V19的关键错误和安全修复，但不是新的功能工作。我们希望在2020中完成C++ 20，然后在H1 2021中工作VxNe–我们不确定我们要在VXRT大修上工作多长时间，尽管我们预期它至少要用6个月。我个人希望一年，但我也想要一匹小马和一只独角兽）。目前，我们还不清楚它将如何发送给用户（即什么版本）。