Setup your dev tools to use C++ 17

Using CLion (or CMake) and setting the CMakeLists.txt CMAKE_CXX_STANDARD to

set(CMAKE_CXX_STANDARD 17)

allows us to use C++ 17 features.

In CLion the intellisense/editor will show folding expressions with red underlines, i.e. as errors in the current release, however the code will compile

Folding Expressions

Basically folding expressions allow us to write code which takes one or more arguments and applies operators to them to create a return value.

In C++ terms, folding expressions take variadic template arguments and unpack the arguments using unary or binary operators to create a return value.

The syntax for folding expressions, is as follows

Syntax (as taken from http://en.cppreference.com/w/cpp/language/fold).

• unary right fold (pack op …)
• unary left fold (… op pack)
• binary right fold (pack op … op init)
• binary left fold (init op … op pack)

Let’s look at some examples to make things clearer using this syntax.

Unary right fold

The following is a simple summation method using unary right fold syntax

template<typename... Args>
auto unary_right_fold(Args... args) {
    return (args + ...);
}

Unary left fold

The following is a simple summation method using unary left fold syntax

template<typename... Args>
auto unary_left_fold(Args... args) {
    return (... + args);
}

Binary right fold

The following is a simple summation + 1 method using binary left fold syntax

template<typename... Args>
auto binary_right_fold(Args... args) {
    return (args + ... + 1);
}

Binary left fold

The following is a simple 1 + summation method using binary left fold syntax

template<typename... Args>
auto binary_left_fold(Args... args) {
    return (1 + ... + args);
}

The only C++ application I now maintain used a single thread to handle background copying and it was fine, but anything more than that and it becomes a little more complex to maintain, especially when compared to threading in C#, such as TPL, Parallel library and async/await.

Now whilst these new features/libraries are not in the same “ease of use” area as those C# classes etc. they are nevertheless a massive step forward.

From what I can tell, we have four different multi-threaded operations (I think that’s the best way to put it). I’m not talking locking, or other forms of synchronization here.

std::thread

So at the most basic level we have the std::thread which is extremely simple to use, here’s an example

auto t = std::thread([]
{
   // do something in a thread
});

We can block (or wait) until the thread has completed using t.join();, but there’s other possibilities for interacting with our thread.

std::future and std::promise

Futures and promises are two sides of the same coin, so to speak. A promise allows us to return state from a thread. Whereas a future is for reading that returned state.

In other words, let’s think of it in this, fairly simple way – we create a promise that really says that at some time there will be a state change or return value from thread. The promise can be used to get a std::future, which is the object that gives us this return result.

So we’ve got the equivalent of a simple producer/consumer pattern

auto promise = std::promise<std::string>();
auto producer = std::thread([&]
{
   // simulate some long-ish running task
   std::this_thread::sleep_for(std::chrono::seconds(5));
   promise.set_value("Some Message");
});

auto future = promise.get_future();
auto consumer = std::thread([&]
{
   std::cout << future.get().c_str();
});

// for testing, we'll block the current thread
// until these have completed
producer.join();
consumer.join();

Note: In the example above I’m simply using a lambda and passing reference to all variables in scope via the capture, using [&], as a capture list is required to access the promise and future outside of the lambdas.

In this example code we simply create a promise and then within the first thread we’re simulating a long-ish running task with the sleep_for method. Once the task is complete we set_value on the promise which causes the future.get() to unblock, but we’ve jumped ahead of ourselves, so…

Next we get the future (get_future) from the promise and to simulate a a producer/consumer we spin up another thread to handle any return from the promise via the future.

In the consumer thread, the call to future.get() will block that thread until the promise has been fulfilled.

Finally, the code calls producer.join() and consumer.join() to block the main thread until both producer and consumer threads have completed.

std::async

The example for the promise/future combination to create a producer consumer can be simplified further using the std::async which basically deals with creating a thread and creating a future for us. So let’s see the code for the producer/consumer now with the std::async

std::future<std::string> future = std::async([&]
{
   std::this_thread::sleep_for(std::chrono::seconds(5));
   return std::string("Some Message");
});

auto consumer = std::thread([&]
{
   std::cout << future.get().c_str();
});

consumer.join();

In the above we’ve done away with the promise and the first thread which have both been replaced with the higher level construct, std::async. We’ve still got a future back and hence still call future.get() on it, but notice how we’ve also switch to returning the std::string and the future using the template argument to match the returned type.

We’re not actually sure if the code within the async lambda is run on a new thread or run on the calling thread, as the async documentation states…

“The template function async runs the function f asynchronously (potentially in a separate thread which may be part of a thread pool) and returns a std::future that will eventually hold the result of that function call.”

So the async method may run the code on a thread or deferred. Deferred meaning the code is run when we call the future’s get method in a “lazy” manner.

We can stipulate whether to run on a thread or as deferred using an std::async overload

std::future<std::string> future = 
   std::async(std::launch::deferred, [&]
   {
   });

In the above we’ve deferred the async call and hence it’ll be run on the calling thread, alternatively we could stipulate std::launch::async, see std::launch.

What about exceptions?

If an exception occurs in async method or the promise set_exception is called in our producer/consumer using a promise. Then we need to catch the exception in the future (call to get()). Hence here’s an example of the async code with an exception occuring

std::future<std::string> future = std::async([&]
{
   throw std::exception("Some Exception");
   return std::string("Some Message");
});

auto consumer = std::thread([&]
{
   try
   {
      std::cout << future.get().c_str();
   }
   catch(std::exception e)
   {
      std::cout << e.what();
   }
});

consumer.join();

Here we throw an exception in the async lambda and when future.get is called, that exception is propagated through to the consumer thread. We need to catch it here and handle it otherwise it will leak through to the application and potentially crash the application if not handled elsewhere.