C++ 1z Coroutines语言功能？

Question

为什么协程(现在在C++ 1z的最新草案中)被实现为核心语言功能(花哨的关键字和所有)而不是库扩展？

已经存在一些针对它们的实现(Boost.Coroutine等),其中一些可以与我所阅读的平台无关.为什么委员会决定将其融入核心语言本身？

我不是说他们不应该,但是Bjarne Stroustrup自己在一些谈话中提到过(不知道哪一个),应该尽可能在图书馆中实现新功能,而不是触及核心语言.

那么有充分的理由吗？有什么好处？

Answer 1

虽然有协同程序的库实现,但这些协议往往具有特定的限制.例如,库协议实现无法检测协程挂起时需要维护哪些变量.可以解决这种需要,例如,通过以某种形式明确使用变量.但是,当协同程序应尽可能地像正常函数一样时,应该可以定义局部变量.

我不认为Boost协同程序的任何实现者认为他们各自的库接口是理想的.虽然它是目前语言中可以实现的最佳选择,但总体使用可以得到改善.

Answer 2

在CppCon 2015上，来自Microsoft的Gor Nishanov提出了这样的论点，即C ++协程可能是负面的开销抽象。他的演讲稿在这里。

如果看一下他的示例，使用协程的能力简化了网络代码的控制流程，并且在编译器级别实现时，可以为您提供较小的代码，其吞吐量是原始代码的两倍。他认为，屈服能力实际上应该是C ++函数的功能。

它们在Visual Studio 2015中具有初始实现，因此您可以针对您的用例进行尝试，并查看其与boost实现的比较。看起来他们仍然在尝试使用Async / Yield关键字，因此请注意标准的去向。

对于C ++的可恢复函数建议可以发现这里和更新这里。不幸的是，它没有进入c ++ 17，但现在是技术规范p0057r2。从好的方面来看，它们似乎在使用-fcoroutines_ts标志的clang中得到了支持，在Visual Studio 2015 Update 2中也得到了支持。这些关键字也带有co_前缀。因此，co_await，co_yield等。

协程是golang，D，python，C＃的内置功能，并将采用新的Javascript标准（ECMA6）。如果C ++提出了更有效的实现，我想知道它是否会取代golang的采用。