Articles & Books

Eggs.Variant - Part II (the constexpr experience)—K-ballo

A link to make type-safe unions:

Eggs.Variant - Part II (the constexpr experience)

by K-ballo

From the article:

Ruminations on the development of Eggs.Variant, a C++11/14 generic, type-safe, discriminated union. Part I explored a straightforward implementation based on untyped raw storage appropriate to hold any of the variant members. It was noted, however, that such an implementation would never be constexpr-aware. It's time to throw it away and start from scratch in order to properly support constexpr...

Bug of the week—Andrzej KrzemieĊ„ski

Here is an interesting bug:

Bug of the week

by Andrzej Krzemieński

From the article:

Today we are going to see a case study illustrating a bug. Not a very spectacular one: a typical bug one would encounter in everyday work. We will start with the symptoms, identify the root cause, and suggest measures to prevent similar things from happening in the future...

Simple and Clean Code vs. Performance—Arne Mertz

This article talks about why simple code is more important.

Simple and Clean Code vs. Performance

by Arne Mertz

From the article:

One of C++s strengths is that it is possible to write very performant code. But does that mean we always have to worry about performance and write our everyday code as performant as possible? Should we give up simplicity for performance? Do we have to?
 

Lock-Free Data Structures. The Evolution of a Stack—Max Khiszinsky

Max Khiszinsky describes in his recent blog article different approaches to develop concurrent containers.

Lock-Free Data Structures. The Evolution of a Stack

by Max Khiszinsky

From the article

Describing the known algorithms would be quite boring, as there would be a lot of [pseudo-]code, plenty of details that are important but quite specific. After all, you can always find them in the references I provide in articles. What I wanted was to tell you an interesting story about exciting things. I wanted to show the development of approaches to designing concurrent containers.

Quick Q: Why does ~shared_ptr amazingly know how to call the right destructor?—StackOvervflow

Quick A: Because shared_ptr is awesome and remembers the correct deleter to call.

Recently on SO:

Why does incomplete type of smart pointer data member and raw pointer data member have different behavior when their parent destruct?

In the following code:

smart pointer data member pImpl(class Impl) and raw pointer pc(class CAT) all are incomplete data type, there is no definition of these two classes in Widget.h ...

... For the raw pointer data member, its destuctor is not called when widget object is destructed.

While the shared_ptr data member, its destructor has been correctly called.

... Why do shared_ptr data member and raw data member have different behavior when the widget gets destructed?

Interview with Scott Meyers at Yandex—Coder_CPP

In case you missed the transcript a few days ago on Reddit:

Interview with Scott Meyers at Yandex

by Coder_CPP

From the interview:

... So I don’t think that in ten years everyone will be using managed languages. I think that C++ is going to remain an extremely important language for production use. Simply because if your goal is to get the maximum of performance out of the machine. If that is what is most important to you. I think that even these days the primary competitors are C and C++. Those are pretty much your choices. And C++ is just a much more expressive language. I have to say that I’m not a C programmer. I've never really been a C programmer. But I think that just a simple notion of destructors is so unbelievably powerful, that as a C programmer I would consider moving to C++ just so I could compile and get destructors. And, obviously, there is a lot more? to it than that...

C++ Tail Recursion Using 64-bit variables—Giovanni Campo

Leveraging the elegance of recursion:

C++ Tail Recursion Using 64-bit variables

by Giovanni Campo

From the article:

Main disadvantage of Recursion in imperative languages is the fact that not always is possible to have tail calls, which means an allocation of the function address (and relative variables, like structs for instance) onto the stack at each call. For deep recursive function this can cause a stack-overflow exception because of a limit to the maximum size of the stack, which is typically less than the size of RAM by quite a few orders of magnitude.

Semaphores are Surprisingly Versatile—Jeff Preshing

An interesting approach on how semaphores could be used in Modern C++ multithreaded programming:

Semaphores are Surprisingly Versatile

by Jeff Preshing

From the article:

In multithreaded programming, it’s important to make threads wait. They must wait for exclusive access to a resource. They must wait when there’s no work available. One way to make threads wait – and put them to sleep inside the kernel, so that they no longer take any CPU time – is with a semaphore.

I used to think semaphores were strange and old-fashioned. They were invented by Edsger Dijkstra back in the early 1960s, before anyone had done much multithreaded programming, or much programming at all, for that matter. I knew that a semaphore could keep track of available units of a resource, or function as a clunky kind of mutex, but that seemed to be about it.

My opinion changed once I realized that, using only semaphores and atomic operations, it’s possible to implement all of the following primitives:

  1. A Lightweight Mutex
  2. A Lightweight Auto-Reset Event Object
  3. A Lightweight Read-Write Lock
  4. Another Solution to the Dining Philosophers Problem
  5. A Lightweight Semaphore With Partial Spinning ...