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

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

CopperSpice: Lambdas in C++

New video on the CopperSpice YouTube Channel:

Lambdas in C++

by Barbara Geller and Ansel Sermersheim

About the video:

In this video, we cover an introduction to C++ lambdas, how they differ from function pointers and functors, and why the term functor should really be avoided. We also give a brief overview of how lambdas have been extended since they were introduced in C++11.

Please take a look and remember to subscribe!

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