Home » Blog » 2019 » June

June 2019

CppCast Episode 201: Pattern Matching with Michael Park

By robwirving | Jun 7, 2019 02:26 PM | Tags: None

Episode 201 of CppCast the first podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Michael Park to discuss his Pattern Matching library and standards proposal.

CppCast Episode 201: Pattern Matching with Michael Park

by Rob Irving and Jason Turner

About the interviewee:

Michael Park is a software engineer at Facebook, working on the C++ libraries and standards team. His focus for C++ is to introduce pattern matching to facilitate better code.

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

By Marco Arena | Jun 5, 2019 06:43 AM | Tags: c++20 c++17 advanced

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

By Adrien Hamelin | Jun 4, 2019 11:04 AM | Tags: intermediate c++14

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]?

By Adrien Hamelin | Jun 4, 2019 11:01 AM | Tags: intermediate

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

By Adrien Hamelin | Jun 3, 2019 11:47 AM | Tags: stl intermediate

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?