Clang 5 in a Docker container for C++17 development--SolarianProgrammer

By Adrien Hamelin | Dec 18, 2017 02:46 PM | Tags: community

Very convenient to create a development environment without hassles.

Clang 5 in a Docker container for C++17 development

by SolarianProgrammer

From the article:

If you want to try the new C++17, using Clang in a Docker container, you are in the right place. Running Clang in a container has the advantage that it is light on resources and won’t mess with your underlying OS. The last point is especially important if your host operating system is macOS, on which it is a really bad idea to directly install a binary Clang other than the one that comes with Xcode. I’ve tested the approach presented in this article on Windows 10, macOS High Sierra and Ubuntu Linux.

Overload 142 is now available

By Adrien Hamelin | Dec 18, 2017 02:42 PM | Tags: community

ACCU’s Overload journal of December 2017 is out. It contains the following C++ related articles.

Overload 142 is now available

From the journal:

Too Fast! Too slow! Too right!!
Many products over-promise. Frances Buontempo muses on how to get things just right. by Frances Buontempo

CAS (Re)Actor for Non-Blocking Multithreaded Primitives
Lock free programming can be difficult. Sergey Ignatchenko shows how copy and swap can work for reactors. by Sergey Ignatchenko

A Design Example
Design issues cause problems. Charles Tolman considers an organising principle to get to the heart of the matter. by Charles Tolman

The Last Word in Patterns
What can you do in a single transaction in a database? Paul Grenyer writes us his Single CrUD pattern. by Paul Grenyer

Implementing Type-Classes as OCaml Modules
Type classes achieve overloading in functional paradigms. Shayne Fletcher implements some as OCaml modules. by Shayne Fletcher

Evolutionary Computing Frameworks for Optimisation
Evolutionary algorithms can find optimal solutions to problems. Aurora Ramírez and Chris Simons give us an overview. by Aurora Ramírez and Chris Simons

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

By Nico Josuttis | Dec 17, 2017 10:50 AM | Tags: c++17

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

By Adrien Hamelin | Dec 15, 2017 01:20 PM | Tags: intermediate

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

By Adrien Hamelin | Dec 11, 2017 12:20 PM | Tags: community c++14

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

By Marco Arena | Dec 11, 2017 11:55 AM | Tags: community

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

By bfilipek | Dec 7, 2017 11:35 AM | Tags: None

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

By bfilipek | Dec 6, 2017 10:51 AM | Tags: basics

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

By Adrien Hamelin | Dec 4, 2017 01:54 PM | Tags: c++11 advanced

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?

By Adrien Hamelin | Dec 1, 2017 02:00 PM | Tags: intermediate c++11

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.