Home » Blog » Categories » Articles & Books

Articles & Books

17 Smaller but Handy C++17 Features--Bartlomiej Filipek

By Adrien Hamelin | Aug 14, 2019 11:04 AM | Tags: c++17

It's not all about the big things.

17 Smaller but Handy C++17 Features

by Bartlomiej Filipek

From the article:

When you see an article about new C++ features, most of the time you’ll see a description of major elements. Looking at C++17, there are a lot of posts (including articles from this blog) about structured bindings, filesystem, parallel algorithms, if constexpr, std::optional, std::variant… and other prominent C++17 additions.

But how about those smaller parts? Library or language improvements that didn’t require decades to standardise or violent “battles” at the ISO meetings.

In this article, I’ll show you 17 smaller C++17 things that will improve your code...

Combining Ranges and Smart Output Iterators--Jonathan Boccara

By Adrien Hamelin | Aug 13, 2019 10:30 AM | Tags: community

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?

By Adrien Hamelin | Aug 13, 2019 10:27 AM | Tags: intermediate

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

By Adrien Hamelin | Aug 7, 2019 11:27 AM | Tags: community c++17

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?

By Adrien Hamelin | Aug 7, 2019 11:06 AM | Tags: advanced

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