Functional Patterns in C++ -- Bartosz Milewski

bartosz-milewski-functional.pngIf you're familiar with functional language styles and you want an advanced look at how your favorite functional styles are supported in modern C++, with a dash of Haskell, check out these three videos by Bartosz Milewski:

Functional Patterns in C++ (slides)

by Bartosz Milewski

Part 1, Functors: First the introduction to some common functional patterns like Functor, which, surprisingly pops up everywhere. I'll show the example of a unique_ptr and a vector as Functors. Of course, this is only in preparation for asynchronous functors.

Part 2, Currying, Applicative: A little digression to Haskell and the Maybe functor and the explanation of currying. Then I'll show you the Applicative Functor pattern. This is, of course, in preparation for for the asynchronous applicative functor pattern.

Part 3, Asynchronous API, Monoid, Monad: The encapsulation of asynchronous API that doesn't lead to inversion of control and spaghetti code. Very natural example of a Monad Pattern.

Slides (parts 1-3)

Interestingly, Bartosz' talk ends with a plea for (essentially) future.then and a C#-style await... both of which are under active consideration in the C++ standards committee as part of a potential near-term C++ technical specification on concurrency and parallelism.

Add a Comment

Comments are closed.

Comments (4)

0 0

ChrisV said on May 2, 2013 04:14 PM:

"nterestingly, Bartosz’ talk ends with a plea for (essentially) future.then and a C#-style await… both of which are under active consideration in the C++ standards committee as part of a potential near-term C++ technical specification on concurrency and parallelism"

Except that N3558 (and in particular future.then) doesn't really address this. To give effect to Bartosz' proposals it would be necessary to have some kind of event loop or message pump on the C# model - a future.when() for want of a better expression. Apart from the rather interesting but probably rarely useful when_any() and make_ready_future(), the remainder is just somewhat complicated syntactic sugar. when_all() can be implemented just by calling get() on all of the futures concerned. then() can be implemented by passing a lambda as the thread function which calls the "then'd" functions.
0 0

jbandela said on May 3, 2013 09:43 PM:

You can have library emulation of C# style await, using the recently released Boost.Coroutine Library. I developed a library for doing so. The code is at https://github.com/jbandela/cpp_async_await

You can use it with Boost.Asio - see http://jrb-programming.blogspot.com/2013/04/c-style-asyncawait-in-c-part-1.html

And with Microsoft PPL/PPLX - see http://jrb-programming.blogspot.com/2013/04/c-style-asyncawait-in-c-part-2-using.html

With PPL/PPLX which is very similar to future.then (I think the proposal was by the same people that created PPL/PPLX), the code comes pretty close in convenience to a language solution. With Boost.Asio because of the irregularities of callbacks, the code is more complicated. In both cases, it avoids the inversion of control problem. When future.then becomes available in standard C++ or Boost, I plan or incorporating support for that in the library as well.

I would be interested if anybody had any feedback or knew of other similar projects.
0 0

ChrisV said on May 4, 2013 03:08 AM:

jbandela: Interesting. Coroutines might be an alternative to a message pump to implement await-type semantics. However, the proposed future::then() itself is in my view a pretense, or if not that then at least useless. Getting any one thread of execution to execute two lambdas consecutively (where the result of the first is passed as an argument to the second) has never been a problem: the language's ordinary function syntax and sequencing rules already deal with that.

The question is how, after a particular thread of execution has executed a series of lambda or other function calls consecutively, does it deliver the end result asynchronously without having another thread's execution stalled waiting for that result and in a way which avoids inversion of control?

That is a hard problem in C++. future::then() does not play a part in the answer. A standardized message pump or standardized implementation for coroutines might.
0 0

olli said on May 13, 2013 12:41 AM:

>The question is how, after a particular thread of execution has executed a series of lambda or other function calls consecutively, does it deliver the end result >asynchronously without having another thread's execution stalled waiting for that result and in a way which avoids inversion of control?

>That is a hard problem in C++. future::then() does not play a part in the answer. A standardized message pump or standardized implementation for coroutines might.

maybe userland threads (using coroutines etc. internaly) implementing future::then() might help