Articles & Books

Space Game: A std::variant-Based State Machine by Example--Nikolai Wuttke

Did you think to use it like that?

Space Game: A std::variant-Based State Machine by Example

by Nikolai Wuttke

From the article:

One of a powerful uses of std::variant is to implement State Machines. Some time ago I showed a simple example, but today we have something bigger. In today’s article by Nikolai Wuttke you’ll see how to leverage std::variant and build a space game!

A simple workaround for the fact that std::equal takes its predicate by value--Raymond Chen

Simple and efficient.

A simple workaround for the fact that std::equal takes its predicate by value

by Raymond Chen

From the article:

The versions of the std::equal function that takes a binary predicate accepts the predicate by value, which means that if you are using a functor, it will be copied, which may be unnecessary or unwanted.

In my case, the functor had a lot of state, and I didn’t want to copy it....

Generic Interfaces with Generic Lambdas using C++ for SYCL -- Georgi Mirazchiyski

This blog post offers a generic description of using lambdas in C++ and how it's possible to use them with SYCL, an open standard interface for programming heterogeneous hardware using C++.

Generic Interfaces with Generic Lambdas using C++ for SYCL

by Georgi Mirazchiyski

From the article:

C++ Lambdas, first introduced in C++11, are an important part of the way that the SYCL standard is defined and implemented. SYCL is required to handle different types and pass around functions so lambdas are a good fit allowing anonymous function objects to be passed to SYCL kernels. We talk about how we use lambdas in our guides and documentation, but never about how lambdas work or even how to use them in SYCL, so in this blog post we will examine how they can be used in SYCL.

Kadane in next-gen C++--Marco Arena

A new interpretation of a classical problem:

Kadane in next-gen C++

by Marco Arena

From the article:

We, programmers, get better results while thinking in patterns. We decompose complex problems in combinations of simpler patterns. However, many problems cannot be solved with known patterns. Here is where creativity kicks in...

Quick Q: Differences between std::make_unique and std::unique_ptr with new

Quick A: mostly for exception safety.

Recently on SO:

Differences between std::make_unique and std::unique_ptr with new

The motivation behind make_unique is primarily two-fold:

make_unique is safe for creating temporaries, whereas with explicit use of new you have to remember the rule about not using unnamed temporaries.

foo(make_unique<T>(), make_unique<U>()); // exception safe

foo(unique_ptr<T>(new T()), unique_ptr<U>(new U())); // unsafe*

The addition of make_unique finally means we can tell people to 'never' use new rather than the previous rule to "'never' use new except when you make a unique_ptr".

There's also a third reason:

make_unique does not require redundant type usage. unique_ptr<T>(new T()) -> make_unique<T>()

None of the reasons involve improving runtime efficiency the way using make_shared does (due to avoiding a second allocation, at the cost of potentially higher peak memory usage).