STL大牛Stephan T. Lavavej访谈

STL大牛Stephan T. Lavavej访谈

作者:BlogUpdater |  时间:2020-10-15 |  浏览:49 |  评论已关闭 条评论

蓝星最熟悉STL的人:Stephan T. Lavavej
STL大牛人Stephan T. Lavavej在CppCon 2020上做了一个十分精彩的演讲,内容涵盖了integer comparison functions, constexpr algorithms, uniform container erasure, atomic_ref和span等,这些主题都搭配了完整的示例程序(而不是代码片段),开发者可以通过这些例子来深入理解最新的STL实现背后的原理。
在Stephan演讲的结尾,观众提出了很多感兴趣的问题,因为时间的关系,他只回答了其中的几个比较典型的问题。下面我们具体来看看他怎么说。

Q: 为什么要压缩PR(Squash pull requests),而不是简单的合并它们?
A: 我们之所以选择这种提交方式,是因为它可以大大简化分支的历史,因为每一次压缩的commit等同于一次PR。你仍然可以在仓库中查看到所有PR的历史记录。如果合并的话,将产生高度非线性化的提交历史记录(这会增加查看代码变更细节的难度,在MSVC的内部仓库里充满了这种非线性的合并提交,这为查看代码变更带来了很大的困难)。
大多数的非压缩合并都是一些不那么令人感兴趣的部分,它们基本上是一些代码Review的反馈,以及开发阶段的Bug修复。对于非常不常见的情况,我可以想象将PR序列化为一系列的commit,然后将其重定向并合并到默认分支,我们需要通过策略临时启用该分支,但通常PR中留下这个历史记录就足够开发者查看了。

Q: 关于atomic_ref,为什么不指定宽松的访问权限呢?
A: 我的理解是,更宽松的访问控制仍然比普通操作更加耗费资源。
例如,在用于MSVC的x86/x64平台上,原子增量由_InterlockedIncrement实现,即使你要求宽松访问,它也会提供完整的顺序一致性。我听说这大约花费10-100个周期,而普通的增量是半个周期或更短。即使在ARM/ARM64上,也有_Meow_nf个内在函数(”no fence”)可以放宽,我相信与普通操作相比,它们仍然隐含着额外的成本。

Q: 你认为将STL开源会提高STL的团队的开发效率吗?有担心过与第三方贡献者的合作会带来太多的开销吗?
A: 这是一个很好的问题。这是我们在开源过程中考虑最多/最为担心的事情之一。
我想说,我们准备在短期内承担间接费用/开发效率的成本,同时希望在长期内提高开发效率。
令人惊讶的是,短期成本低于预期,而且我们已经享受开发效率的增长,例如:由于我们不具备深厚的数字专业知识,因此midpoint/lerp一直都进展很慢,直到statementreply做出了精彩的PR分析并解决了剩下的问题。
我乐观地相信,团队的开发效率将会得到进一步提升。我对C++23及更高版本的计划是,将在基于STL的实现来编写提案,以便PR可以在STL尽快进行审查和合并并被标准委员会所接,受这将提高标准化质量和开发效率。

Q: 对于已发行的二进制文件,是否与Microsoft面向公众的符号和源服务器集成在一起,以便调试器在调试过程中可以提取正确版本的源代码?
A: 答案是,VS产品的构建方式以及与符号服务器的交互方式没有任何变化,因此一切将继续和一起一样工作。
GitHub是我们进行所有开发的地方,并且通过将PR复制到MSVC,确保存储库与MS内部src/vctools /crt/github树是二进制相同的。接下来的流程是:构建产品,将源打包到VS Installer,然后将PDB上传到符号服务器。
在不久的将来,我们可能会通过GitHub CI系统构建正式的二进制文件,然后通过某种机制将它们捆绑到VS中-但是我们还不太确定应该如何构建这种机制,这涉及很大一部分的工作量。
通过简单地完成构建系统的迁移,然后使内部MS内部的MSVC的MSBuild系统(好多的MS!),调用我们用于GitHub的CMake/Ninja构建系统,我们应该能够节省大部分时间。
我们已经为LLVM ASAN支持库提供了此类CMake调用。

Q: 您是否遇到过这样的情况,即标准中的设计不那么实用? 你有没有向标准委员会报告呢?
A: 是的,这种情况经常发生。在”此设计对实现者或用户而言不是很好” 和 “此规范不清楚/与其他实践不一致/内部不一致/违反动量守恒” 之间还是有区别的。
对于前者(次优设计),我们有时会在Library Evolution Working Group中提及它,尤其是在开发新功能时,但是在某个功能被草案接受后,通常就为时已晚了。(也并非总是如此,因为可以在发布国际标准之前对功能进行修改;发生过这种情况的是span,在C++20完成之前,span收到了一个无符号的size_type类型)。
后者(伪规范)很常见,我们将这些报告给 通常可以迅速解决的Library Working Group(作为LWG问题)。同时,我们会根据自己的最佳判断来实施可能的标准以及标准”应该说的”内容。

Q: 为什么不适用于wchar_t?
A: 这个问题,应该留给Jens Maurer来回答,因为他提出了这个功能的。
我的理解是charconv只是一个最简化版本的API,其思想是主要用于JSON或者其他只需要处理char类型的API。但是,即使出于有限的浮点解析目的,也将wchar_t转换为char并返回,这非常不方便/缓慢,并且to_chars最终比当时L[E]WG中任何人都意识到的快得多(正如Ulf Adams发明的那样,Ryu和Ryu Printf在功能被接受之后),因此wchar_t转换的开销变得更加重要。
尽管charconv极其复杂,但是使其成为wchar_t的对象,只是一个简单的模板化与字符交互的代码路径的问题,表格和核心算法不需要重复编写。

Q: 做出开源代码的决定,是自上而下的?还是团队不得不说服管理层,这是一个好主意?
A: 这是一个有趣的问题。我想我可以说这是一个自下而上的决定。
Mahmoud Saleh(我的老板,VC Libraries开发负责人) 在MSVC的其他部门的支持下推动了这个审批过程。我们确实必须让我们的老板们相信这是一个好主意,但这不是一场斗争,这是对基本原理,成本/收益以及对公开工作的后果进行思考的有益练习。从上至下的策略变化无疑使这一切成为可能,对于10年前的Microsoft来说,开源是不可想象的,现在我们一直在寻找对STL和.NET Core有意义的地方(我们在开源过程中与该团队进行了交流,以了解我们将面临的挑战和机遇,它们非常有帮助)。

我们正在寻找的机会是可以提高整个C++社区利益的地方,因此,当程序员考虑C++的未来时,他们自然会想到Microsoft。例如,当主要的工具链以高质量及时地支持最新功能时,所有C++程序员都将从中受益Microsoft来说,开源是不可想象的,现在我们一直在寻找对STL和.NET Core有意义的地方(我们在开源过程中与该团队进行了交流,以了解我们将面临的挑战和机遇,它们非常有帮助)。

我们正在寻找的机会是可以提高整个C++社区利益的地方,因此,当程序员考虑C++的未来时,他们自然会想到Microsoft。例如,当主要的工具链以高质量及时地支持最新功能时,所有C++程序员都将从中受益。
因此,Microsoft投入了大量的开发人员和多年的努力来实现标准的一致性,以至于MSVC通常是第一个实现新功能的团队。STL是开放源代码的最引人注目的机会,原因有几个:它是一个相对较小的代码库和测试套件(绝对量来说很大-毕竟是标准的一半!-但比编译器或其他大型项目小) , 我们已经在交付其源代码以供查看,因此”仅仅是”更改许可证的问题,库的发展日新月异,并且(也许最重要的是)库往往没有深度互连,因此可以添加或在不了解和更改其他所有内容的情况下进行更改。
现在,我们已经有了像GCC的libstdc++和Clang/LLVM的libc++这样的开源标准库,我们希望以一种适用于所有平台的形式,来更加容易地提出新的标准库功能。

Q: 学习所有最新STL功能的最佳方法是什么? 有在线教程吗? 函数风格? 您的团队中有专家写书吗?
A: 我想说,最好的方法是自己实现它。
没有一个STL实现者会有时间写书,但是我们正在与Microsoft Docs团队的Tyler Whitney合作,因为他为我们已经添加的各种功能添加了文档。cppreference也是社区积累的良好信息来源。我通常认为,学习功能的最佳方法,除了实现它之外,最好是先在简单的示例中尝试使用它,在简单干净的环境中熟悉基础知识,然后再在实际环境中以基本方式使用它,然后再进行高级使用。
尝试立即在生产代码库中使用新功能可能会令人头疼,因为您可能不会立即看到问题是由于尝试错误地使用功能本身本身引起的,还是由与代码库的交互引起的(“我知道通常使用此功能,所以这里出了什么问题? 哦,它需要可复制性,但是这种类型只能移动”)或其他。如果您找到更好的技术,请告诉我!也可以直接阅读库标准,它非常详细。缺点是它以某种奇怪的风格编写,有时信息被”隐藏”在其他地方(例如,容器规范以一种不寻常的方式高度集中),但是通常可以找到函数签名和基本类型要求以及值前提条件办法。对于普通人(相对于出色的编译器开发人员)而言,核心语言标准的理解要困难得多,但我要说的是,因为我是专门从事STL的库开发者,因为与编译器开发相比,它很容易。

Q: 它会是VS 2019 16.8.0 Preview 3.0的一部分吗?
A: 是的,我描述的所有功能今天都可以在该版本中使用。
我们认为它们具有生产环境级别的质量,通常的警告是VS不支持Preview版本的”上线”,并且/ std:c++latest在技术上被认为是实验性的,并且可能会发生变化。
(请注意,我们可以并且已经破坏了/std:c++最新功能的ABI,当我们完成C++20并添加/std:c++20时,ABI锁定将发生。因此,任何使用/std:c++lastest构建的东西,确实需要使用最新的工具集。但是,如果您想生活在C++的最前沿,那应该不成问题)

Q: vNext何时会成为具体版本?
A: 我们的计划仍然是暂定的,可能会有所更改,但是我们计划在完成C++20之后以干净的切换方式在vNext上工作。
也就是说,VS2019(从VS2015开始的”v19″发行系列)将接收所有C++20功能,然后执行vNext,然后C ++23功能将仅添加到vNext。我们将继续为v19提供关键错误和安全修复服务,但不会为新功能提供服务。我们希望在2020年完成C++20,然后在2021年上半年进行vNext的工作,尽管我们预计vNext大修至少需要6个月,但我们不确定我们将需要进行多长时间的工作。
目前,我们尚不清楚确切如何将其交付给用户(即什么版本)。

最后
Microsoft Visual C++团队的博客是我非常喜欢的博客之一,里面有很多关于Visual C++的知识和最新开发进展。大浪淘沙,如果你对Visual C++这门古老的技术还是那么感兴趣,则可以经常去他们那(或者我这)逛逛。
本文来自:《C++20 STL Features: 1 Year of Development on GitHub》

标签:

评论已关闭。