Articles & Books

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;
}

Quick Q: How to (and who can) implement the standard library features defined by the C++ committee?

Quick A: Everyone by reading and applying the C++ standard.

Recently on SO:

How to (and who can) implement the standard library features defined by the C++ committee?

The committee does not release any reference implementations. In the early days, things got standardized and then the tool developers went away and implemented the standard. This has changed, and now the committee looks for features that have been implemented and tested before standardization.

Also major developments usually don't go directly into the standard. First they become experimental features called a Technical Specification or TS. These TS may then be incorporated into the main standard at a later date.

You are free to write you own implementation of the C++ standard library. Plum Hall has a test suite (commercial, I have no connection, but Plum Hall are very involved with C++ standardization).

I don't see any issue with not being conformant. Almost all implementations have some extensions. Just don't make any false claims, especially if you want to sell your product.

If you're interested in getting involved, this can be done via your 'National Body' (ANSI for the USA, BSI for the UK etc.). The isocpp web site has a section on standardization which would be a good starting place.

Your own error code--Andrzej Krzemieński

The stl can help you!

Your own error code

by Andrzej Krzemieński

From the article:

I was recently implementing the “classification of error conditions” in my application offered by the functionality behind std::error_code. In this post I want to share some of my experience and insight.

Zero-allocation continuations in C++17 — Vittorio Romeo

This series of articles show the design and implementation of future-like asynchronous computation chains that do not require any dynamic memory allocation or type erasure. 

by Vittorio Romero

From the article:

I'd like to show an alternative design [for futures] that doesn't require any allocation whatsoever and still enables users to build up asynchronous computation chains using facilities such as `when_all` and `.then`. [...] The idea behind it is to encode the entire computation chain into a single object with a huge type.

Trip report: Summer ISO C++ standards meeting (Toronto) -- Herb Sutter

wg21-toronto-city-e1500123984972.pngThe Toronto ISO C++ meeting just concluded:

Trip report: Summer ISO C++ standards meeting (Toronto)

by Herb Sutter

From the article:

A few minutes ago, the ISO C++ committee completed its summer meeting in Toronto, Ontario, Canada. We had some 130 people at the meeting, representing nine national bodies. As usual, we met for six days Monday through Saturday, including several evenings.

The following are some highlights of what we achieved this week...

Future Ruminations -- Sean Parent

This post is a lengthy answer to a question from Alisdair Meredith via Twitter

Future Ruminations

by Sean Parent

From the article:

The question is regarding the numerous proposals for a better future class template for C++, including the proposal from Felix Petriconi, David Sankel, and myself.

It is a valid question for any endeavor. To answer it, we need to define what we mean by a future so we can place bounds on the solution. We also need to understand the problems that a future is trying to solve, so we can determine if a future is, in fact, a useful construct for solving those problems.

The proposal started with me trying to solve a fairly concrete problem; how to take a large, heavily threaded application, and make it run in a single threaded environment (specifically, compiled to asm.js with the Emscripten compiler) but also be able to scale to devices with many cores. I found the current standard and boost implementation of futures to be lacking. I open sourced my work on a better solution, and discussed this in my Better Code: Concurrency talk. Felix heard my CppCast interview on the topic, and became the primary contributor to the project.