C++17 brings us parallel algorithms. However, there are not many implementations where you can use the new features. The situation is getting better and better, as we have the MSVC implementation and now Intel’s version will soon be available as the base for libstdc++ for GCC. Since the library is important, I’ve decided to see how to use it and what it offers.

Thank you for all the comments about the string_view performance! Last week I got a lot of feedback on how to improve the initial string split code. Have a look at how can we update the code and get some better performance. Intro Last week I showed a few examples of string_view.

How much is std::string_view faster than standard std::string operations? Have a look at a few examples where I compare std::string_view against std::string. Intro I was looking for some examples of string_view, and after a while, I got curious about the performance gain we might get. string_view is conceptually only a view of the string: usually implemented as[ptr, length].

Writing articles about modern C++ features is a lot of fun, but what’s even better is to see how you use those new things in real world. Today I’m happy to present a guest post article from JFT who was so kind to describe his project where he uses several C++17 features.

MSVC (VS 2017 15.7, end of June 2018) is as far as I know the only major compiler/STL implementation that has parallel algorithms. Not everything is done, but you can use a lot of algorithms and apply std::execution::par on them! Have a look at few examples I managed to run.

Show me your code! I’d like to run a little experiment. Let’s build a wall of examples of std::optional! Intro In the last three articles of my C++17 STL series I’ve been discussing how to use std::optional. I can talk and talk… or write and write… but I’m wondering how do you use this wrapper type?

This post is motivated by one important comment from my last article about factories and self-registering types: (me) So the compiler won’t optimize such variable. Yet, unfortunately, the linker will happily ignore it if linking from a static library. So… what’s the problem with the linker?

Writing a factory method might be simple: unique_ptr<IType> create(name) { if (name == "Abc") return make_unique<AbcType>(); if (name == "Xyz") return make_unique<XyzType>(); if (...) return ... return nullptr; } Just one switch/if and then after a match you return a proper type. But what if we don’t know all the types and names upfront?

Let’s see pimpl and its alternatives in a real application! I’ve implemented a small utility app - for file compression - where we can experiment with various designs. Is it better to use pimpl or maybe abstract interfaces? Read on to discover. Intro In my previous post I covered the pimpl pattern.

Is C++ well suited for writing fast small utilities/tools? Let’s see: For my recent giveaway I needed a tool that would take an input file - CSV with data and then draw a few winners from all of the entries. To make things more complicated each entry might have a different weight.

When doing my last performance tests for bool packing, I got strange results sometimes. It appeared that one constant generated different results than the other. Why was that? Let’s have a quick look at branching performance. The problem Just to recall (first part, second part) I wanted to pack eight booleans (results of a condition) into one byte, 1 bit per condition result.

Let’s continue with the topic of packing boolean arrays into bits. Last time I’ve shown a basic - single threaded version of this ‘super’ advanced algorithm. By using more independent variables, we could speed things up and go even faster than no packing version! We’ve also used std::vector and std::bitset.