As you might notice from reading this blog, I love doing performance optimizations. Let’s take some algorithm or some part of the app, understand it and then improve, so it works 5x… or 100x faster! Doesn’t that sound awesome? I hope that you answered “Yes” to the question in the introduction.

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. Today I’d like to look at making the task parallel.

Imagine you have an array of booleans (or an array of ‘conditions’), and you want to pack it - so you use only one bit per boolean. How to do it? Let’s do some experiments! Updated: 8th May 2017 Read the second part here and also one update. Motivation   I started writing this post because I came across a similar problem during my work some time ago.

Last time I wrote about final_act utility, and it seems I’ve stepped into a bigger area that I wasn’t aware of. Let’s continue with the topic and try to understand some of the problems that were mentioned in the comments. Intro   Let’s remind what was the case last time:

Sometimes there’s a need to invoke a special action at the end of the scope: it could be a resource releasing code, flag set, code guard, begin/end function calls, etc. Recently, I’ve found a beautiful utility that helps in that cases. Let’s meet gsl::final_act/finally. Intro   Follow-up post here: link.

As you’ve might already notice I’ve made a little joke on Saturday, which was the April Fools’ Day. I got the courage to announce C++18 next year! :) While it was a bit funny, I didn’t expect much traffic (as it was Saturday). Still, my stats shows that a lot of people clicked and viewed the post.

I have a great news! During the last meeting in Kona, the committee not only made final notes on the C++17 standard! There’s also a groundbreaking news that behind the curtains they planned C++18! Disclaimer/Note: this was just an April Fool’s joke! :). Please read the follow-up here! Intro   As it appears, the C++ Cometee finally understood that C++17 doesn’t contain the features everyone wanted.

You want to transform one file into another, input into output. What API will you choose on Windows? WinApi? C++ Streams or good old stdio? Last year in September I looked at four ways of processing a file on Windows. Also, I did some performance tests. The whole project description was recently published in Visual Studio Magazine.

There are probably billions of lines of code written in C++ already. New code is being written every day. But will this trend continue? Will you be able to find a C++ job in five years? Let’s have a quick view. The Story   This post was motivated by a recent video from J.

One of the guidelines from Modern C++ is to avoid using raw new and delete. Instead, you should use a smart pointer, a container or other RAII object. Today I’d like to focus on so-called ‘sink functions’ that takes ownership of input parameters. How can we modernize code around such calls?

C++ is a surprising language. Sometimes, simple things are more complex in practice. In my article about “use const all the time”, I argued that in function bodies const should be used most of the time. But two cases were missed: when moving and when returning a value. Let’s revise this topic today.