Articles & Books

C++17 - The Complete Guide -- Nicolai M. Josuttis

The first draft of "C++17 - The Complete Guide" is now available at

C++17 - The Complete Guide

by Nicolai M. Josuttis

About the guide:

Buy early, pay less, free updates.

This book uses a new publishing model: It is written incrementally and self-published. That way you can buy it even before it is complete and I have income while I am still writing it (note that I do C++ for a living).

Most of the new features are covered already in detail:

  • All major new core language features
  • The new library components (filesystem only by a few examples)

But there is still enough to do (see http://www.cppstd17.com/ for details).

All covered features went through significant review with awesome feedback and already have a lot of useful details including how they integrate with other features and discussing all the traps you should avoid.

Mixin Classes: The Yang of the CRTP--Jonathan Boccara

Some template tricks.

Mixin Classes: The Yang of the CRTP

by Jonathan Boccara

From the article:

Now that we’re clear on how the CRTP works, let me share with you another technique involving templates that is complementary to the CRTP: Mixin classes. I learnt about mixin classes by watching Arthur O’Dwyer’s Template Normal Programming talk at CppCon (actually you can find them in the slides because they were skipped over during the presentation)...

C++17 Feature Removals And Deprecations--Stephan T. Lavavej

This is about visual studio, but this is also about how the deprecated mechanisms work.

C++17 Feature Removals And Deprecations

by Stephan T. Lavavej

From the article:

Technology advances by inventing new ways of doing things and by discarding old ways. The C++ Standardization Committee is simultaneously adding new features and removing old features at a gradual pace, because we’ve discovered thoroughly better ways of writing code. While feature removals can be annoying, in the sense that programmers need to go change old codebases in order to make them conform to new Standards, they’re also important. Feature removals simplify the Core Language and Standard Library, avoiding the doom of accreting complexity forever. Additionally, removing old features makes it easier to read and write code. C++ will always be a language that offers programmers many ways to write something, but by taking away inferior techniques, it’s easier to choose one of the remaining techniques which are more modern...

C++ Day 2017--Marco Arena

My report on the last C++ event we organized in Italy:

C++ Day 2017

by Marco Arena

From the article:

At the beginning of December, on the 2nd, the Italian C++ Community hosted the C++ Day 2017 and about 110 people gather together...

Summary of C++17 features

Slides from a talk about C++17 features 

Summary of C++17 features

by Bartlomiej Filipek

From the article:

How do you see the new C++ standard? Is it ok? Great? Meh? See my slides from the talk where I tried to answer this question.

5 ways how unique_ptr enhances resource safety in your code -- Bartlomiej Filipek

Examples where unique_ptr shines:

5 ways how unique_ptr enhances resource safety in your code

by Bartlomiej Filipek

From the article:

While shared_ptr and weak_ptr are more complex, unique_ptr seems to be a perfect replacement for owning raw pointers. Not to mention is the fact that this pointer type is mostly a compile time “wrapper” and it cost almost nothing in the runtime.

Your own type predicate--Andrzej KrzemieĊ„ski

A very detailled and complete article to start playing with template predicates!

Your own type predicate

by Andrzej Krzemieński

From the article:

In this post we will see how to define a type trait or a type predicate or a meta-function that would allow us to check at compile time whether a type exposes an interface that we need. That is, we want to check if a given type T has:

  • nested typename result_type,
  • static member function set_limit that takes one argument of type int,
  • member function get_result that returns type const result_type& and that is declared not to throw exceptions...

Quick Q: May a destructor be final?

Quick A: Yes, as any other virtual member function.

Recently on SO:

May a destructor be final?

May a C++ destructor be declared as final?

Yes.

And if so, does that prevent declaration of a derived class:

Yes, because the derived class would have to declare a destructor (either explicitly by you or implicitly by the compiler), and that destructor would be overriding a function declared final, which is ill-formed.

The rule is [class.virtual]/4:

If a virtual function f in some class B is marked with the virt-specifier final and in a class D derived from B a function D​::​f overrides B​::​f, the program is ill-formed.

It's the derivation itself that is ill-formed, it doesn't have to be used.

Is declaring a destructor to be final a workable idiom for indicating that a class is not intended to be used as a base class?

Effectively, but you should just mark the class final. It's quite a bit more explicit.

C++ Coroutines: Understanding operator co_await--Lewis Baker

An article very complete!

C++ Coroutines: Understanding operator co_await

by Lewis Baker

From the article:

In the previous post on Coroutine Theory I described the high-level differences between functions and coroutines but without going into any detail on syntax and semantics of coroutines as described by the C++ Coroutines TS (N4680).

The key new facility that the Coroutines TS adds to the C++ language is the ability to suspend a coroutine, allowing it to be later resumed. The mechanism the TS provides for doing this is via the new co_await operator.

Understanding how the co_await operator works can help to demystify the behaviour of coroutines and how they are suspended and resumed. In this post I will be explaining the mechanics of the co_await operator and introduce the related Awaitable and Awaiter type concepts.

But before I dive into co_await I want to give a brief overview of the Coroutines TS to provide some context...

code::dive Trip Report

Adi Shavit reports from the recent code::dive conference

code::dive Trip Report

by Adi Shavit

From the article:

The code::dive conference took place last week in Poland at the beautiful city of Wrocław (pronounced VROWTS-WAF). I had seen excellent videos of talks from previous years and this year promised a roster of distinguished speakers.
I had never been to a C++ conference before and beyond the talks I was looking forward to meeting face-to-face many of my online Slack, Twitter and GitHub friends, followers and followees, as well as many of the speakers whose work I’ve been following online through blogs, repos and videos.