Articles & Books

Quick Q: Undefined behavior and sequence points

Quick A: No quick A.

Recently on SO:

Undefined behavior and sequence points

What are "sequence points"?

What is the relation between undefined behaviour and sequence points?

I often use funny and convoluted expressions like a[++i] = i;, to make myself feel better. Why should I stop using them?

If you've read this, be sure to visit the follow-up question Undefined behavior and sequence points reloaded.

(Note: This is meant to be an entry to Stack Overflow's C++ FAQ. If you want to critique the idea of providing an FAQ in this form, then the posting on meta that started all this would be the place to do that. Answers to that question are monitored in the C++ chatroom, where the FAQ idea started out in the first place, so your answer is very likely to get read by those who came up with the idea.)

Quick Update on C++ Compiler Bug Hunt—No Bugs” Hare

Looking for the bug.

Quick Update on C++ Compiler Bug Hunt

by No Bugs" Hare

From the article:

Some time ago, I wrote a post about kscope – mini-project on finding and reporting bugs in modern C++ compilers. The point was that there is a way to use C++ facilities to make C++ code self-mutating (more strictly – pseudo-randomized using externally supplied ITHARE_KSCOPE_SEED macro), which allows finding certain classes of bugs during randomized testing. In the previous post, I wrote about 12 bugs reported, with 3 of them already fixed. I have to admit that since that point, I didn’t have as much time as I’d like to spend on kscope; still, 3 more bugs were reported (2 of them being codegen bugs) – and quite a few were fixed (fortunately, bugfixing is one thing which doesn’t require my participation <wink />)...

Using C++17 std::optional—Bartlomiej Filipek

A reminder.

Using C++17 std::optional

by Bartlomiej Filipek

From the article:

Let’s take a pair of two types <YourType, bool> - what can you do with such composition?

In this article, I’ll describe std:optional - a new helper type added in C++17. It’s a wrapper for your type and a flag that indicates if the value is initialized or not. Let’s see where it can be useful and how you can use it.

std::iterator is deprecated: Why, What It Was, and What to Use Instead—Jonathan Boccara

You've been warned.

std::iterator is deprecated: Why, What It Was, and What to Use Instead

by Jonathan Boccara

From the article:

C++17 has deprecated a few components that had been in C++ since its beginning, and std::iterator is one of them.

If you don’t have C++17 in production, you’re like most people today. But one day or the other, your will have it, most likely. And when that day comes, you’ll be glad you anticipated the deprecation of such components, and stopped using them well in advance.

Let’s see how std::iterator was used, why it was deprecated, and what to use instead.

‘Speedy Gonzales’ Serializing (Re)Actors via Allocators—“No Bugs” Hare


‘Speedy Gonzales’ Serializing (Re)Actors via Allocators

by "No Bugs" Hare

From the article:

As we briefly discussed in Part I of this mini-series [NoBugs17a], message-passing technologies such as (Re)Actors (a.k.a. Actors, Reactors, ad hoc FSMs, and event-driven programs) have numerous advantages – ranging from being debuggable (including post-factum production debugging), to providing better overall performance.

In [NoBugs17a] and [NoBugs17b], we discussed an approach to handling allocations for (Re)Actors, and then were able to achieve a safe dialect of C++ (that is, as long as we’re following a set of well-defined local rules). Now, let’s take a look at another task which can be facilitated by per-(Re)Actor allocators – specifically, at the task of serializing (Re)Actors that are later going to be de-serialized by the same executable. While one solution for this task was provided in [Ignatchenko-Ivanchykhin16], the proposed ‘ultra-fast’ serialization is rather cumbersome to maintain, and in most cases it can be beaten performance-wise by serializing at the allocator level...

Passing Booleans to an Interface in an Expressive Way—Jonathan Boccara

Readability is important.

Passing Booleans to an Interface in an Expressive Way

by Jonathan Boccara

From the article:

In order to allow a function to behave in several different way, and to allow its caller to choose amongst these behaviours, we have several tools at our disposal. Plenty, actually.

There are various sorts of polymorphisms embedded in the language such as virtual functions and templates. And we’ve also seen that a caller can specify the desired behaviour explicitly at call site. We’ve seen how to accomplish this by using tag dispatching, and also how to choose between enums and tag dispatching depending on your need.

I now want to top it off with a really simple technique, that will cost you almost nothing, but one that will make your code much more expressive. And even if it’s not rocket science I’m sharing this with you today because I’ve seen many a piece of code that could have benefited from it...

Without form and void—Barry Revzin

Did you encounter the problem?

Without form and void

by Barry Revzin

From the article:

In C++, void is a pretty strange thing. We can cast expressions to void, throw-expressions have void type, void* can point to anything, and void functions can actually return back to the caller. But we can’t have objects of type void or even write a type like void&. A function declaration like void f(void) is actually a nullary function. It’s a bit weird — but it’s not something a lot of people lose sleep over.

Until it starts wreaking havoc on your generic code — because it’s like the vector<bool> of the type system...

[[trivial_abi]] 101—Arthur O’Dwyer


[[trivial_abi]] 101

by Arthur O’Dwyer

From the article:

Finally, a blog post on [[trivial_abi]]!

This is a brand-new feature in Clang trunk, new as of about February 2018. It is a vendor extension to the C++ language — it is not standard C++, it isn’t supported by GCC trunk, and there is no active WG21 proposal to add it to the standard C++ language, as far as I know...

When to Use Enums and When to Use Tag Dispatching in C++—Jonathan Boccara

What is your preference?

When to Use Enums and When to Use Tag Dispatching in C++

by Jonathan Boccara

From the article:

Enums and tag dispatching are two ways to introduce several behaviours in the same interface in C++. With them, we can pass arguments that determine a facet of how we want a function to behave.

Even if enums and tag dispatching have that in common, they achieve it in a quite different way. Realizing what these differences are will give you tools to decide which one to use in any given situation...

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...