intermediate

string_view odi et amo--Marco Arena

string_view has recently joined the C++ standard and it can dramatically help your daily job. In this article, after introducing how it works, I show and discuss a few common pitfalls I have met in the last years:

string_view odi et amo

by Marco Arena

From the article:

string_view-like wrappers have been successfully used in C++ codebases for years, made possible by libraries like boost::string_ref. I think all of you know that string_view has joined the C++ standard library since C++17...

Folding Functions--Sumant Tambe

Let's use those fold operators!

Folding Functions

by Sumant Tambe

From the article:

In the last post we looked at basic usage of C++17 Fold Expressions. I found that many posts on this topic discuss simple types and ignore how folds may be applicable to more complex types as well. In this post I'm going to describe folding over functions...

Building a hybrid spin mutex in C++ -- Foster Brereton

Forster Brereton reports about his first steps to build a hybrid mutex.

Building a hybrid spin mutex in C++

by Foster Brereton

From the article

Blocking Mutexes
A blocking mutex will halt the thread until it acquisition. It is useful because it consumes negligible computer resources while blocked. This leaves the CPU free to perform other tasks, including whatever other task currently owns the mutex. All this goodness is not cheap, however: it takes a decent amount of time to block thread. If your critical section is brief, you could be spending a disproportionate amount of time protecting it instead of running it.
Generally, blocking mutexes should be used when your critical section will take a while, such as I/O operations, calling out to the OS, or doing laundry in a collegiate dorm.


Spinning Mutexes
A spinning mutex will enter into an infinite loop (spin) until acquisition. It is useful because it can resume very quickly once the lock has been obtained, resulting in minimal overhead while protecting a critical section. However, since the thread remains active on the CPU, it can reduce (or eliminate!) the ability of the CPU to do other work††. If your critical section is long, you could be spending a disproportionate amount of time protecting it instead of running it.
Generally, spin mutexes should be used when your critical section is brief, such as reading or writing a memory-resident data structure.

Finding a middle ground
The dichotomy between the two mutex behaviors has left me stuck more than once. What if I was trying to protect a global resource that occasionally required a call to the OS? In those cases a blocking mutex is not a good fit, as modifying the memory-resident structure is pretty quick. However a spin mutex would be equally bad, because I do need to go to the OS time and again, and it would be a pessimization to spike a CPU while doing so.

More Meeting C++ 2016 videos are online!

A week full of video editing brings the first batch of Meeting C++ 2016 videos online:

More videos are online!

by Jens Weller

Meeting C++ 2016 Playlist

From the article:

With today, almost all videos from the A and all videos of the D Track are online. There is a recording issue with one talk in the A track, which might get resolved in 2017. Also since today, the Meeting C++ YouTube channel has more then 400k views!

The full video set you can find in the Meeting C++ 2016 Playlist, the newest videos are easily found by visiting the Meeting C++ YouTube channel or subscribing to this RSS feed.

When noexcept?--Edouard of quasardb

A good question with a good answer.

When noexcept?

by Edouard of quasardb

From the article:

In a previous post, we had a look at the new constexpr keyword that has been introduced in C++ 11. Today we'll study another new fancy specifier: noexcept...

The One-Definition Rule--Andrzej Krzemieński

Something we should be aware of:

The One-Definition Rule

by Andrzej Krzemieński

From the article:

We have been hit by the same bug twice already this year. It ends in a crash, and it took developers days to find it (in each case), even though it is reproducible on each run of unit tests. The code, after significant simplifications, looks like this:

namespace tests
{
  struct Fixture
  {
    std::vector<int> v1;
    std::vector<int> v2;

    static Fixture create();
  };

  TEST_CASE(test1)
  {
    auto fixture = Fixture::create();
    std::cout << "running test1";
  }
}