Articles & Books

Prepping Yourself to Conceptify Algorithms -- Christopher Di Bella

In this article, we explore what concepts are, where they are useful, and how they are different to things that exist in vanilla C++17.

Prepping Yourself to Conceptify Algorithms

by Christopher Di Bella

From the article:

A very quick summary of this document is that constraints are requirements imposed on syntax, axioms are requirements imposed on semantics, and concepts are both constraints and axioms together.

...

Let’s build the EqualityComparableWith concept from the Ranges TS, from the ground up.

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

See how and when std::optional from C++17 is useful:<img alt="" data-cke-saved-src="https://dl.dropboxusercontent.com/s/nv9s71vz8kq8pq3/stdoptusing.png?dl=0" src="https://dl.dropboxusercontent.com/s/nv9s71vz8kq8pq3/stdoptusing.png?dl=0" 400px;="" height:="" 128px;="" float:="" right;"="" style="height: 74px; width: 230px; float: right;">

Using C++17 std::optional

by Bartlomiej Filipek

From the article:

By adding the boolean flag to other types, you can achieve a thing called “nullable types”. As mentioned, the flag is used to indicate whether the value is available or not. Such wrapper represents an object that might be empty in an expressive way (so not via comments smile)

Non-Ownership and Generic Programming and Regular types, oh my!==Barry Revzin

Do you know about it?

Non-Ownership and Generic Programming and Regular types, oh my!

by Barry Revzin

From the article:

This post is about a specific collection of types in the C++ core language and standard library. I am not sure of a good way to name this collection, and some terms that come to mind come with their own baggage, so I’m going to for now group them together under an umbrella that is clearly widely unrelated to programming and call them Westie types (because, like my dog, they are awesome yet enigmatic).

IO2D demo: CPULoad -- Michael Kazakov

A walkthrough of the CPULoad demo from the 2D Graphics proposal:

IO2D demo: CPULoad

by Michael Kazakov

From the article:

In my humble opinion, the 2D graphics proposal might bring C++ a solid foundation for visualization support. It’s powerful enough to build complex structures on top of it – here I can refer to the sample SVG renderer as an example. At the same time, it’s not built around some particular low-level graphics API (i.e OpenGL/DirectX/Mantle/Metal/Vulkan), which come and go over time (who remembers Glide?). What is also very important about the proposal is its implementability – I wrote the CoreGraphics backend in ~3 months on a part-time basis. It can be assumed that writing a theoretical Direct2D backend might take about the same time. While it’s easy to propose “just” a support for PostScript, SVG or even HMTL5, the practical implementability of such extensive standards is very doubtful. Having said that, I do think that the proposal, while being a valid direction, is far from being perfect and needs a lot of polishing.

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

Actors.

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