I’ve been asked a few times to post the slides of my talk online. Lets hope we’ll have the videos soon as well.
The slides are now available on SlideShare.
Slides from Qt Dev Days: continuations, asynchronous APIs, etc.
Ivan Čukić
dr Ivan Čukić
Author of "Functional Programming in C++", KDE developer and Free/Libre software enthusiast
For inquiries about KDE projects (requesting features, submitting bugs, asking general questions etc.), you can use:
KDE Community Forum
Bug reporting site
#plasma IRC channel
You need to contact me directly?
KDE related:
ivan.cukic [at] kde.org
Non KDE related things:
ivan [at] this domain
IRC Network: libera.chat
Nick: ivan|home
Channel: #plasma
Projects
Blog categories
Functional Programming in C++
If you like C++,
you might be interested in my book.
It contains quite a few gems
of modern C++ programming.
It is available for purchase at:
It is available for purchase at:
Patronage
Related:
Comments:
-
@Matthias
That is nice to know. High hopes for await then :)
-
@Kevin
Agreed. If they pull it out properly, life will be fine. :)
-
@Matthias
Maybe it will. I didn't see any mention of that proposal in the resumable functions one.
-
True, limitations caused by C++ not having native support for event loops.
Anyway, I was mainly commenting on the resulting code, i.e. it is by far the best readable way of doing sequences of asynchronous calls.
Makes one hope that the standard implementation will enable integration into event loops for those who want to use C++ to its full potential.
I mean, the Vala compiler has to implement this in C! A C++ compiler should be able to do that as well, maybe even better.
-
@Kevin The easiest, in some/half/most cases yes.
But consider the following: <em>"A resumable function may continue execution on another thread after resuming following a suspension of its execution."</em> (n3564, page 4). This means that, if we use it with Qt, we can not have any UI code in that method because it might be invoked from a non-UI thread.
Furthermore, it means implicitly enabling a thread based execution even if we only want to do a single-thread reactive programming (boost::asio as a perfect example). So, we could potentially end up with a couple of thread pools - STL's, Qt's, ThreadWeaver's etc.
The fact that we don't have an event loop in the standard, and that this doesn't use one can lead to a lot of issues like above.
-
@Kevin I am really not sure about those. Adding a separate, completely different ways to generate code depending on whether an async method was called in it... That, along with lack of control of how it is all done in back-end (relying on thread pool, not knowing about event loop, etc.)
As a feature, looks nice, but I'm a bit worried how it will all turn out. If it goes in at all.
-
It is the easiest way I've encountered so far, since it allows asynchronous code to be written almost exactly like the synchronous equivalent.
Vala has that (or had that when I tried it a couple of years back) and it was fantastic!
-
I am looking forward to resumable functions: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3564.pdf
-
Right, it's not in the proposal. But SG1 feedback was that a follow-up paper needs to discuss how N3722 will tie in with execution agents. Since Niklas is also involved with the executors proposal (N3731) I have high hopes. :)
-
Have you seen the executers proposal? It contains a loop_scheduler which would become the standard event loop for C++. I am certain that resumable functions in C++ will tie in with the execution agents provided through the standard library.
