Faces of undefined behavior

I have been busy recently (doing C++-related stuff) and cannot find a spare time for preparing a decent blog post. I expect that to change in November. For the interim I am posting here my last year’s talk at code::dive: Faces of undefined behavior. It is relevant in the context of recent discussions about contracts in C++ and go-back-in-time optimizations.

Functions in std

Names of functions from the Standard Library used as pointers/references to functions can cause breakage in your code if you are upgrading to the newer version of C++ or compiling using a different implementation of the Standard Library, or even when just adding headers. In this post we will see why this is so, and what we can do about it.

Rvalues redefined

In this post we will explore what I consider the most significant language change in C++17. I call it the most significant because it changes the way you design your resource-managing types and how you think about initialization. It is often called “guaranteed copy elision”, but I will not use that name (except for this single time) because it does not reflect what this feature is. C++ has completely changed the meaning of rvalue (actually, prvalue).

Testing C++ online

In this short post I wanted to share links to three online services that I use for testing different aspects of C++ and C++ compilers.

• https://wandbox.org/ — this allows you to compile and observe the output of programs compiled in different versions of GCC and Clang, with different versions of Boost libraries;
• https://godbolt.org/ — this allows you to see the assembly of C++ programs generated with different compilers on different platforms;
• http://quick-bench.com/ — this allows you to micro-benchmark C++ functions on different versions of GCC and Clang using Google’s benchmark library.

String’s competing constructors

Let’s start with the problem. I want to check whether a program received a text message that consists of four consecutive zeroes. Not '0', but the numeric zero. I will create a constant std::string representing the special sequence and compare the messages (also stored as std::strings) I receive. I cannot just type:

const std::string Special = "\0\0\0\0";

As this would be interpreted, according to C rules, as a zero-length string. But there is another constructor exactly for our case, where I can say “character C repeated N times”. So, I type:

const std::string Special ('\0', size_t(4));

I could have used braces for the initialization, but since I am aware of the std::initializer_list gotchas (like the one described here), I am following my rule of thumb, “if you suspect the type might expose an initializer-list constructor, and you want to initialize through a different constructor, do not use braces”.

Now I can test my program. It still doesn’t work correctly for some reasons. It does not recognize the special messages as special, even though I would expect it to. I test and debug it for quite some time, until finally do I realize that my string Special has a different value than I think.

Help the compiler warn you

Compiler warnings are a very useful tool for detecting bugs in your program. Because you can enable them selectively, and because you can choose to turn them into hard errors on your compiler, you can in fact build a dialect, which is a safer subset of C++. You can enable even more warning if you assist your compiler a bit and instruct it about your intentions. We will see how to do it in one case.

A friendly type predicate

This is a sequel to the previous post on writing a custom type predicate. One of the readers on Reddit made a very insightful observation. The user has implemented a type that she intends to use with our library, call it Calc. She passes it to the library function, and she gets the compiler error:

static assertion failed: X does not have a desired interface

But what is our type missing? In the previous post we were describing 3 constraints. A concept could have far more of them. The user has already made an effort to have Calc comply with the constraints, so there must be something tiny missing. Maybe there is a bug in the implementation of the predicate? But it is difficult to track what it is that the predicate does not like about our type. We could use some more specific information.