Your handy cut-out-and-keep guide to std::forward and std::move—Glennan Carnie

Do you know it?

Your handy cut-out-and-keep guide to std::forward and std::move

by Glennan Carnie

From the article:

I love a good ‘quadrant’ diagram.  It brings me immense joy if I can encapsulate some wisdom, guideline or rule-of-thumb in a simple four-quadrant picture.

This time it’s the when-and-where of std::move and std::forward.  In my experience, when programmers are first introduced to move semantics, their biggest struggle is to know when (or when not) to apply std::move or std::forward.  Usually, it’s a case of “keep apply std::move until it compiles”.  I’ve been there myself.

To that end I’ve put together a couple of a simple overview quadrant graphics to help out the neophyte ‘mover-forwarder’.  The aim is to capture some simple rules-of-thumb in an easy-to-digest format...

Exceptional exploration (1)—Lucian Radu Teodorescu

Are you exceptionally curios?

Exceptional exploration (1)

by Lucian Radu Teodorescu

From the article:

To use or not to use exceptions? That is the question.

And if you have hoped for a simple answer, this is not the right blog to read. On this blog, finding the truth is always a complex endeavor, it involves a complex mix of perspectives and a variety of interpretations. If you are into truthing, read on.

In this post we would only cover the performance aspects of it. A follow up post should discuss aspects like modifiability (how easy is to write error handling) and appropriateness of using exceptions.

Quick Q: How can unique_ptr have no overhead if it needs to store the deleter?

Quick A: The default deleter does not store anything.

Recently on SO:

How can unique_ptr have no overhead if it needs to store the deleter?

std::unique_ptr<T> is quite likely to be zero-overhead (with any sane standard-library implementation). std::unique_ptr<T, D>, for an arbitrary D, is not in general zero-overhead.

The reason is simple: Empty-Base Optimisation can be used to eliminate storage of the deleter in case it's an empty (and thus stateless) type (such as std::default_delete instantiations).

Refactoring with C++17 std::optional—Bartlomiej Filipek

Isn't it better?

Refactoring with C++17 std::optional

by Bartlomiej Filipek

From the article:

There are many situations where you need to express that something is “optional” - an object that might contain a value or not. You have several options to implement such case, but with C++17 there’s probably the most helpful way: std::optional.

For today I’ve prepared one refactoring case where you can learn how to apply this new C++17 feature...

How to Reorder A Collection With the STL—Jonathan Boccara

Did you know?

How to Reorder A Collection With the STL

by Jonathan Boccara

From the article:

The STL lets you do plenty of things on collections, and one of them is to reorder the elements inside of the collection. Or, said another way, to perform a permutation on the collection.

Inded, moving elements around a collection typically takes a fair amount of complex code to write, involving for loops and iterators. And it is perhaps the area where the STL generates the most spectacular improvements, by encapsulating those complex operations behing meaningful interfaces.

Let’s see what sorts of permutations the STL offers:

  • Lexicographical permutations
  • Cyclic permutations
  • Random permutation
  • Reverse
  • Checking for permutations
  • Other permutations

optional in Containers Ⅱ — Not All std::vector Usages Are The Same—Jonathan Müller

What do you think?

optional<T> in Containers Ⅱ — Not All std::vector Usages Are The Same

by Jonathan Müller

From the article:

Okay, so in the previous post I talked about putting optional<T> in container. I came to conclusions which I though were reasonable at the time, however, people — rightfully — pointed out some flaws in my argumentation...

How to Pass a Polymorphic Object to an STL Algorithm—Jonathan Boccara

Did you ever try?

How to Pass a Polymorphic Object to an STL Algorithm

by Jonathan Boccara

From the article:

As we can read in the opening chapter of Effective C++, C++ is a federation of 4 languages:

  • the procedural part coming from C,
  • the object-oriented part,
  • the STL part (following a functional programming paradigm),
  • the generic part with templates.

And what’s more, all of those 4 sub-languages are part of one whole: the C++ language. Those 4 paradigms begin united in one language gives opportunities for them to interact – and often, those interactions create interesting situations.

Today we’re focusing on one particular interaction, between the object-oriented model and the STL. There could be multiple forms for this interaction, and the case we will look at is how to pass a polymorphic (that is, having virtual methods) function object to an STL algorithm.