intermediate

The Regular Expression Library--Rainer Grimm

A quick introduction.

The Regular Expression Library

by Rainer Grimm

From the article:

My original plan was it to write about the rules of the C++ Core Guidelines to the regex and chrono library, but besides the subsection title, there is no content available. I already wrote a few posts about time functionality. So I'm done. Today, I fill the gap and write about the regex library.

Quick Q; Concise explanation of reference collapsing rules requested: (1) A& & -> A&...

Quick A: the result is the same as calling the function you're forwarding to directly.

Recently on SO:

Concise explanation of reference collapsing rules requested: (1) A& & -> A& , (2) A& && -> A& , (3) A&& & -> A& , and (4) A&& && -> A&&

The reference collapsing rules (save for A& & -> A&, which is C++98/03) exist for one reason: to allow perfect forwarding to work...

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

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?

Quick Q: When should I make explicit use of the `this` pointer?

Quick A: to disambiguate.

Recently on SO:

When should I make explicit use of the `this` pointer?

Usually, you do not have to, this-> is implied.

Sometimes, there is a name ambiguity, where it can be used to disambiguate class members and local variables. However, here is a completely different case where this-> is explicitly required.

Consider the following code:

template<class T>
struct A {
   int i;
};

template<class T>
struct B : A<T> {

    int foo() {
        return this->i;
    }

};

int main() {
    B<int> b;
    b.foo();
}

If you omit this->, the compiler does not know how to treat i, since it may or may not exist in all instantiations of A. In order to tell it that i is indeed a member of A<T>, for any T, the this-> prefix is required.

Note: it is possible to still omit this-> prefix by using:

template<class T>
struct B : A<T> {

    using A<T>::i; // explicitly refer to a variable in the base class

    int foo() {
        return i; // i is now known to exist
    }

};