CppCon 2015: Gor Nishanov “C++ Coroutines - a negative overhead abstraction"

What people said

Strong rec Atif · 2016-02 · Stack Overflow · on “Why wasn't yield added to C++0x?”

So it looks like it didn't make it into C++11, or C++14, but might be on its way to C++17. Take a look at the lecture C++ Coroutines, a negative overhead abstraction [this video] from CppCon2015 and the paper here [LINK] . To summarize, they are working to extend c++ functions to have yield and await as features of functions. Looks like they have an initial implementation in Visual Studio 2015, not sure if clang has an implementation yet. Also it seems their may be some issues with using yield and await as the keywords. The presentation is interesting because he speaks about how much it simplified networking code, where you are waiting for data to come in to continue the sequence of processing. S

Recommends Atif · 2016-02 · Stack Overflow · on “C++1z Coroutines a language feature?”

At CppCon 2015, Gor Nishanov from Microsoft made the argument that C++ Coroutines can be a negative overhead abstraction [this video] . The paper from his talk is here [LINK] . If you take a look at his example, the ability to use a coroutine simplified the control flow of the network code, and when implemented at the compiler level gives you smaller code that has twice the throughput of the original. He makes the argument that really the ability to yield should be a feature of a C++ function. They have an initial implementation in Visual Studio 2015, so you can give it a try it out for your use-case and see how it compares to the boost implementation. It looks like they are still trying to hash

Recommends Atif · 2016-02 · Stack Overflow · on “How do you implement Coroutines in C++”

For those who want to know how they may leverage Coroutines in a portable way in C++ y̶o̶u̶ ̶w̶i̶l̶l̶ ̶h̶a̶v̶e̶ ̶t̶o̶ ̶w̶a̶i̶t̶ ̶f̶o̶r̶ ̶C̶+̶+̶1̶7̶ the wait is over (see below)! The standards committee is working on the feature see the N3722 paper [LINK] . To summarize the current draft of the paper, instead of Async and Await, the keywords will be resumable, and await. Take a look at the experimental implementation in Visual Studio 2015 to play with Microsoft's experimental implementation. It doesn't look like clang has a implementation yet. There is a good talk from Cppcon Coroutines a negative overhead abstraction [this video] outline the benefits of using Coroutines in C++ and how it affects

Recommends Charlie · 2016-05 · Stack Overflow · on “How to create async/await code in C++?”

'await' is a part of a pending proposal from MS for C++ coroutines - looks like some of it may be usable in some versions of Visual Studio [this video] for a presentation on it from last year's cppcon.

Recommends Matthieu M. · 2023-06 · Stack Overflow · on “Is there any performance advantage to use async/await amid synchronous code?”

In theory, yes. At CppCon 2015, Gor Nishanov presented his work on an experimental coroutine implementation for C++: C++ coroutines - a negative overhead abstraction [this video] . C++ coroutines are somewhat different (even implementation-wise) then Rust async/await, but the difference doesn't matter here. The key highlight of the talk was that certain algorithms could get a speed up from using coroutines by exploiting memory pre-fetching. While from the point of view of the code, a memory access is typically synchronous, it is actually asynchronous at the CPU level. The trick, then, is to: Trigger the pre-fetch. Suspend execution -- and do something else. Resume execution, at which point the pr

Cites DuckQueen · 2016-10 · Stack Overflow · on “Is there any reason for "co_" wording in new C++ standard?”

Reasons for this syntax: no one at cppcon knows [LINK] Reasons against it: It all worked perfectly with out co_ see here [this video] and was expected (e.g. taught in universities) Complicated code (the more chars we type the more errors we get) Can be harder to understand and move from other languages (where return and await wording is used [this video] ) So why we co_ wording is there while co_ less sintax was compiler supported in 2015?

Cites allyourcode · 2017-01 · Stack Overflow · on “Equivalent C++ to Python generator pattern”

All answers that involve writing your own iterator are completely wrong. Such answers entirely miss the point of Python generators (one of the language's greatest and unique features). The most important thing about generators is that execution picks up where it left off. This does not happen to iterators. Instead, you must manually store state information such that when operator++ or operator* is called anew, the right information is in place at the very beginning of the next function call. This is why writing your own C++ iterator is a gigantic pain; whereas, generators are elegant, and easy to read+write. I don't think there is a good analog for Python generators in native C++, at least n

Cites David Haim · 2017-03 · Stack Overflow · on “Why is async considered better performing than multithreading?”

(In this answer, I will talk about .NET, as it is the first technology which came out with async/await ) We use threads to parallelize CPU-bound tasks, and we use asynchronous IO to parallelize IO-bound tasks. CPU - wise: We all know that a thread per task is wrong. we don't want too many threads, because the context switches will freeze the entire system. we don't want too few of them, because we want the tasks to be finished as soon as possible. of-course, we're looking at some sort of a threadpool. ThreadPool was the default way of scheduling an asynchronous task on the pre Task epoch. but the threadpool had one sore problem - it was really hard to know when the asynchronous is finished,

Cites jhcarl0814 · 2021-01 · Stack Overflow · on “Different behavior of boost::future and std::future”

[LINK] The returned futures behave as the ones returned from boost::async, the destructor of the future object returned from then will block. This could be subject to change in future versions. (2015) [LINK] Version 4.5.0 - boost 1.58 Fixed Bugs: #10968 The futures returned by async() and future::then() are not blocking. (2017) [LINK] I'm aware of the issue. Boost.thread did it by design following std::async and the first proposals of std::future::then. The problem is that changing the behavior (even if it is not desired in some contexts) would be a breaking change. I would need to crate a new version, but Idon't want to create a new version using compiler flags as this has become a nightmar