为什么协程（现在在C ++ 1z的最新草案中）被实现为核心语言功能（花哨的关键字和所有）而不是库扩展？
已经存在一些针对它们的实现（Boost.Coroutine等），其中一些可以与我所读取的平台无关。为什么委员会决定将其融入核心语言本身？
我不是说他们不应该，但Bjarne Stroustrup自己在一些谈话中提到过（不知道哪一个），应尽可能在图书馆中实施新功能，而不是触及核心语言。 / p>
那么有充分理由这样做吗？有什么好处？
答案 0 :(得分：7)
虽然有协同程序的库实现，但这些往往有特定的限制。例如，库协议实现无法检测协程挂起时需要维护哪些变量。可以解决这种需要，例如，通过以某种形式使用过的变量。但是，当协同程序尽可能像正常函数一样运行时，应该可以定义局部变量。
我认为Boost协程的任何实现者都不认为他们各自的库接口是理想的。虽然它是目前语言中最好的，但总体使用可以得到改善。
答案 1 :(得分：4)
在CppCon 2015上，来自微软的Gor Nishanov提出了C ++协程可以a negative overhead abstraction的论点。他演讲的论文是here。
如果你看一下他的例子，使用协程的能力简化了网络代码的控制流程，并且在编译器级别实现时，为你提供了比原始代码吞吐量高两倍的更小代码。他提出的论点是，屈服的能力应该是C ++函数的一个特征。
他们在Visual Studio 2015中有一个初始实现，因此您可以针对您的用例试一试，看看它与boost实现的比较。看起来他们仍然会尝试使用Async / Yield关键字，但是请密切关注标准的位置。
可以找到C ++的可恢复功能提案here和更新here。不幸的是，它没有进入c ++ 17，但现在是技术规范p0057r2。从好的方面来看，它们似乎支持使用-fcoroutines_ts标志和Visual Studio 2015 Update 2中的clang。关键字也有一个co_前置。所以co_await，co_yield等。
Coroutines是golang，D，python，C＃中的内置功能，将采用新的Javascript标准（ECMA6）。如果C ++提出了更高效的实现，我想知道它是否会取代golang的采用。
答案 2 :(得分：2)
来自C ++ 1z的可恢复函数支持无堆栈上下文切换，而boost.coroutine（2）提供了堆栈上下文切换。
不同之处在于，对于堆栈上下文切换，在协程中调用的函数的堆栈帧在挂起上下文时保持不变，而子目录的堆栈帧在挂起可恢复的函数（C ++ 1z）时被删除。 / p>