C++|VS2019中C++20的协程实现( 二 )

如果你的代码依赖于C++20中未采用的扩展，则从/await迁移到/await:strict可能需要修改源代码。与标准模式一样，它使用头文件头和std命名空间，因此你的代码将为C++20做好准备。使用/await:strict编译的代码使用与/std:c++latest相同的协程ABI ，因此协程对象在两种模式之间可以保持兼容。
我们鼓励/await的所有用户迁移到/await:strict 。你可以利用所有新的协程功能，并确保协程代码在你可以移动到正式支持协程的C++语言版本时为C++20做好准备。我们希望在未来的某个时候弃用和彻底地删除/await开关。
稳定性改进Visual Studio 2019 v16.11版本中还包括几个重要的修复程序，以提高协程的稳定性和可靠性。
最大的变化与优化器如何进行所谓的”提升”有关，这是一种决定哪些变量被放置在协程框架上以及哪些变量保留在(传统)堆栈上的算法。许多协程错误可以追溯到此处的错误决策。通常，这表现为崩溃，或者在协程恢复执行后变量具有不正确或随机的值。此算法已被重写为更准确，结果是更少的崩溃和更小的协程帧大小。旧算法仍然可以通过将/d2CoroNewPromotion-传递给cl.exe来访问。
一个相关的修复涉及如何存储异常对象。异常的生命周期规则可能会变得复杂，需要在决定变量提升时专门处理它们。
发现并修复了与协程中的catch块相关的错误。在某些情况下(即，当try块中唯一的抛出调用来自用户定义的awaiter方法时) ，优化器可能会错误地断定catch块已死，并错误地将其删除。编译器现在知道awaiter方法可以抛出。
最后，解决了一个与调用析构函数的方式和时间有关的严重问题。这涉及如何在协程中跟踪某些对象的构造状态，这些对象在离开作用域时有条件地销毁。在使用条件(三元)运算符构造对象时，它最常出现。该错误表现为此类临时对象的析构函数未被调用，或者在某些情况下被调用两次。这也已在 v16.11版本中修复。
总结我要是有空，我就试试这个新的开关：/await:strict 。异步操作确实比较吸引我。
最后Microsoft Visual C++团队的博客是我非常喜欢的博客之一，里面有很多关于Visual C++的知识和最新开发进展。大浪淘沙，如果你对Visual C++这门古老的技术还是那么感兴趣，则可以经常去他们那(或者我这)逛逛。
本文来自：《C++20 Coroutine Improvements in Visual Studio 2019 version 16.11》