experimental

Ranges, Coroutines, and React: Early Musings on the Future of Async in C++—Eric Niebler

Eric Niebler shares his thoughts about the interaction of ranges and co-routines in his recent blog post.

Ranges, Coroutines, and React: Early Musings on the Future of Async in C++

by Eric Niebler

From the article:

Another way to look at this is that synchronous ranges are an example of a pull-based interface: the user extracts elements from the range and processes them one at a time. Asynchronous ranges, on the other hand, represent more of a push-based model: things happen when data shows up, whenever that may be. This is akin to the reactive style of programming.

By using ranges and coroutines together, we unify push and pull based idioms into a consistent, functional style of programming. And that’s going to be important, I think.

Trip Report: C++ Standards Meeting in Toronto, July 2017—Botond Ballo

Another report:

Trip Report: C++ Standards Meeting in Toronto, July 2017

by Botond Ballo

From the article:

A couple of weeks ago I attended a meeting of the ISO C++ Standards Committee (also known as WG21) in Toronto, Canada (which, incidentally, is where I’m based). This was the second committee meeting in 2017; you can find my reports on previous meetings here (November 2016, Issaquah) and here (February 2017, Kona). These reports, particularly the Kona one, provide useful context for this post.

CppCon 2016: Iterator Haiku—Casey Carter

Have you registered for CppCon 2017 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2016 for you to enjoy. Here is today’s feature:

Iterator Haiku

by Casey Carter

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Iterator Haiku: How five iterator categories blossomed into seven, and Sentinels trimmed them back to five again. Recently proposed changes to the ranges TS distill its seven iterator categories back to five without sacrificing any expressive power. Removing operations that are extraneous in the Sentinel world eliminates a potential source of programming errors.

Yielding Generators—Kirit Sælensminde

The series continue!

Yielding Generators

by Kirit Sælensminde

From the article:

We've seen how the promise_type together with the coroutine return type handles the interactions between the caller and the coroutine itself.

Our target is to be able to do something pretty simple:

generator count() {
    std::cout << "Going to yield 1" << std::endl;
    co_yield 1;
    std::cout << "Going to yield 2" << std::endl;
    co_yield 2;
    std::cout << "Going to yield 3" << std::endl;
    co_yield 3;
    std::cout << "count() is done" << std::endl;
}

CppCon 2016: There and Back Again: An Incremental C++ Modules Design—Richard Smith

Have you registered for CppCon 2017 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2016 for you to enjoy. Here is today’s feature:

There and Back Again: An Incremental C++ Modules Design

by Richard Smith

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

The Clang project has been working on Modules in one form or another for many years. It started off with C and Objective-C many years ago. Today, we have a C++ compiler that can transparently use C++ Modules with existing C++ code, and we have deployed that at scale. However, this is very separate from the question of how to integrate a modular compilation model into the language itself. That is an issue that several groups working on C++ have been trying to tackle over the last few years.

Based on our experience deploying the core technology behind Modules, we have learned a tremendous amount about how they interact with existing code. This has informed the particular design we would like to see for C++ Modules, and it centers around incremental adoption. In essence, how do we take the C++ code we have today, and migrate it to directly leverage C++ Modules in its very syntax, while still interacting cleanly with C++ code that will always and forever be stuck in a legacy mode without Modules.

In this talk we will present our ideas on how C++ Modules should be designed in order to interoperate seamlessly with existing patterns, libraries, and codebases. However, these are still early days for C++ Modules. We are all still experimenting and learning about what the best design is likely to be. Here, we simply want to present a possible and still very early design direction for this feature.