Articles & Books

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).

Quick Q: With arrays, why is it the case that a[5] == 5[a]?

Quick A: See below

Recently on SO:

With arrays, why is it the case that a[5] == 5[a]?

The C standard defines the [] operator as follows:

a[b] == *(a + b)

Therefore a[5] will evaluate to:

*(a + 5)

and 5[a] will evaluate to:

*(5 + a)

a is a pointer to the first element of the array. a[5] is the value that's 5 elements further from a, which is the same as *(a + 5), and from elementary school math we know those are equal (addition is commutative).

The Difference Between std::copy_backward and std::copy with Reverse Iterators—Jonathan Boccara

What do you think?

The Difference Between std::copy_backward and std::copy with Reverse Iterators

by Jonathan Boccara

From the article:

A couple of months ago, I made a talk at the ACCU conference about learning every algorithm there is in the STL. Amongst them, we covered std::copy_backward, that makes a copy of a source range to a destination range, starting from its end and working its way back to the beginning.

In the questions session at the end of the talk, attendant Oscar Forner rose an interesting point: is there any difference between performing a std::copy_backward versus performing a simple std::copy on the reverse iterators from the source collection?

strong_typedef - Create distinct types for distinct purposes—Anthony Williams

A common problem with a common solution made easier.

strong_typedef - Create distinct types for distinct purposes

by Anthony Williams

From the article:

One common problem in C++ code is the use of simple types for many things: a std::string might be a filename, a person's name, a SQL query string or a piece of JSON; an int could be a count, an index, an ID number, or even a file handle. In his 1999 book "Refactoring" (which has a second edition as of January 2019), Martin Fowler called this phenomenon "Primitive Obsession", and recommended that we use dedicated classes for each purpose rather than built-in or library types...