Articles & Books

Combining Ranges and Smart Output Iterators--Jonathan Boccara

And the next one.

Combining Ranges and Smart Output Iterators

by Jonathan Boccara

From the article:

In our current stage of development of smart output iterators, we have:

  • some iterators, such as filter, transform, unzip or demux,
  • the possibility to combine them: filter(pred) >>= transform(f) >>= unzip(back_inserter(output1), back_inserter(output2))
  • their usage as the output iterator of an STL algorithm:
std::copy(begin(inputs), end(inputs), transform(f) >>= back_inserter(outputs));

What we’re going to work on today is removing the call to std::copy to have a pipeline made of output iterators only. And once we get such a pipeline, we will plug it to ranges, in order to benefit from the expressiveness of both ranges and smart output iterators, in the same expression...

Quick Q: When to use virtual destructors?

Quick A: When you might delete polymorphically.

Recently on SO:

When to use virtual destructors?

Virtual destructors are useful when you might potentially delete an instance of a derived class through a pointer to base class:

class Base
{
    // some virtual methods
};

class Derived : public Base
{
    ~Derived()
    {
        // Do some important cleanup
    }
};

Here, you'll notice that I didn't declare Base's destructor to be virtual. Now, let's have a look at the following snippet:

Base *b = new Derived();
// use b
delete b; // Here's the problem!

Since Base's destructor is not virtual and b is a Base* pointing to a Derived object, delete b has undefined behaviour...

C++ Core Guidelines: Supporting Sections--Rainer Grimm

Table of contents.

C++ Core Guidelines: Supporting Sections

by Rainer Grimm

From the article:

Let's recapitulate. In the last two years, I have written about 100 posts to the C++ Core Guidelines. Why? The document answers:  "This document is a set of guidelines for using C++ well. The aim of this document is to help people to use modern C++ effectively.". But my story does not end here. The guidelines have a supporting section...

Quick Q: Where and why do I have to put the “template” and “typename” keywords?

Quick A: to help the compiler understand what the programmer wants.

Recently on SO:

Where and why do I have to put the “template” and “typename” keywords?

In order to parse a C++ program, the compiler needs to know whether certain names are types or not. The following example demonstrates that:

t * f;

How should this be parsed? For many languages a compiler doesn't need to know the meaning of a name in order to parse and basically know what action a line of code does...

Quick Q: What are copy elision and return value optimization?

Quick A: optimisation compilers are allowed to do for perfomance.

Recently on SO:

What are copy elision and return value optimization?

Copy elision is an optimization implemented by most compilers to prevent extra (potentially expensive) copies in certain situations. It makes returning by value or pass-by-value feasible in practice (restrictions apply).

It's the only form of optimization that elides (ha!) the as-if rule - copy elision can be applied even if copying/moving the object has side-effects...

Enabling Polymorphism in SYCL using the C++ idiom "Curiously Recurring Template Pattern"

Dynamic polymorphism is a widely used C++ feature that allows code to be more flexible, and helps create easily extendable interfaces by overriding the base class specified interfaces inside our derived classes. However, in SYCL kernel code in order to emulate dynamic polymorphism we need to use some curious tricks and techniques.

Enabling Polymorphism in SYCL using the C++ idiom "Curiously Recurring Template Pattern"

by Georgi Mirazchiyski

From the article:

The CRTP idiom offers an alternative approach to polymorphism by providing us with the ability to specify static interfaces, where the base class specifies the the structure of the interface, while the derived one represents the implementation. In this case, the base class does represent the interface and the derived class represents the implementation — similar to the general idea of polymorphism.

Why Static Analysis Can Improve a Complex C++ Codebase

Gradually and imperceptibly we get the situation when C++ projects’ complexity becomes extreme. Unfortunately, now a C++ programmer can’t be on his own.

Why Static Analysis Can Improve a Complex C++ Codebase

by Andrey Karpov

From the article:

Analyzers know more than even professional developers. It has become too difficult to take into account and remember all the nuances when writing code. For instance, if you haven’t specifically read about it, you’ll never guess that calls to memset function for clearing private data sometimes disappear, as from a compiler’s point of view, a call to memset function is redundant. Meanwhile, it is a serious security defect CWE-14 that is detected literally everywhere.

Comparisons in C++20--Barry Revzin

Get familiar with it, it's coming and it's going to help you!

Comparisons in C++20

by Barry Revzin

From the article:

Now that the Cologne meeting is over and we’ve more or less finalized (at least before the NB comments come in) C++20, I wanted to take the time to describe in detail one of the new language features we can look forward to. The feature is typically referred to as operator<=> (defined in the language as “three-way comparison operator” but more colloquially referred to as “operator spaceship”), but I think it has broader scope than that.

We’re not just getting a new operator, we’re significantly changing the semantics of how comparisons work at a language level...