What is Modern C++?

We often speak about classical and modern C++. What does that mean? First of all: What is modern C++?. There is a simple and a not so simple answer? The simple answer is. Modern C++ stands for C++ that is based on C++11, C++14, and C++17. I guess you know it. This post and a series of further posts are about the not so simple answer.

With C++11 we had a revolution. That revolutions became with C++14 and will become with C++17 to an evolution. An overview of the timeline of C++ features makes my point clear.

If you look at the sheer amount of features we got since C++11 and the reason for their impact, you must come to the conclusion: C++ before 2011 and since 2011 are different languages. The first is called classical C++, the second modern C++. Therefore, the idiomatic way to program C++ before and after 2011 is totally different.

Now you already know it. I want to answer the question. How does this powerful feature changed the way we think about programming in C++? That is the not so simple question I want to answer.

Two resources

I'm not alone in my search. There are great resources available. Here are two of them.

C++ Best Practices

C++ Best Practices from Jason Turner is a "Collaborative Collection of C++ Best Practices". It's a highly valuable source for modern software development with C++ and general considerations of good C++ code. These general considerations include the safety, maintainability, portability, threadability, and performance of the code.

Today, I will not emphasise the general considerations of the code, I will emphasise the collection of tools he provides in his C++ Best Practices.

His C++ Best Practices includes a collection of a lot of tools for

• source control
• building software,
• continuous-integration
• compilers such as gcc, clang, and msvc
• static code analysis 
• runtime checkers
• testing
• debugging

If you are a professional software developer - I guess you are because you read the post - and have to make a decision on what tools you should use in your professional software development process you should use this great resource to get an idea of what tools are available.

Today, I want to give you an idea of what I will write about in the next posts. My main topic will be the C++ Core Guidelines.

C++ Core Guidelines

Here are the goals from the abstract: "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. By "modern C++" we mean C++11 and C++14 (and soon C++17)."

The editors are Bjarne Stroustrup and Herb Sutter.

The C++ Core Guidelines are a set of more than 100 rules. These rules are divided into major sections and supporting sections. Here are the major sections.

• In: Introduction
• P: Philosophy
• I: Interfaces
• F: Functions
• C: Classes and class hierarchies
• Enum: Enumerations
• R: Resource management
• ES: Expressions and statements
• E: Error handling
• Con: Constants and immutability
• T: Templates and generic programming
• CP: Concurrency
• SL: The Standard library
• SF: Source files
• CPL: C-style programming
• Pro: Profiles
• GSL: Guideline support library
• FAQ: Answers to frequently asked questions

I want to have a closer look at the Introduction section. It deals with meta-rules such as:

• In.target: Target readership
• In.aims: Aims
• In.not: Non-aims
• In.force: Enforcement
• In.struct: The structure of this document
• In.sec: Major section

Let me paraphrase the meta-rules. The target reader is even a C programmer. The aim of the rules is to help developers to adopt modern C++ (C++11, C++14, and soon C++17). These rules emphasise static type safety and resource safety. You should understand the rules because they are prescriptive. The rules have aims and non-aims. They are not intended to be minimal or orthogonal, should be read serially, are not a substitute for tutorial treatment. The rules are either a guide to port old C++ code to new one nor should they be exact in each language detail, or enforce an impoverished subset of C++, or are value-neutral or perfect. Each rule has an enforcement section because the guidelines should help people to make their code uniform and modernise them. The rules follow a uniform structure. The structure consists of the points 

• Rule 
• Rule Reference Number
• Reason 
• Examples
• Alternatives
• Exceptions
• Enforcement of how the rule might be checked "mechanically"
• See alsos
• Notes 
• Discussion 

To be honest that strongly reminds me of the (design) pattern literature. 

To make the intent of the structure clear here is a short example the rule R.22. The R stands for resource management:

R.22: Use make_shared() to make shared_ptrs

Reason

If you first make an object and then give it to a shared_ptr constructor, you (most likely) do one more allocation (and later deallocation) than if you use make_shared() because the reference counts must be allocated separately from the object.

Example

Consider:

shared_ptr<X> p1 { new X{2} }; // bad
auto p = make_shared<X>(2);    // good

The make_shared() version mentions X only once, so it is usually shorter (as well as faster) than the version with the explicit new.

Enforcement

(Simple) Warn if a shared_ptr is constructed from the result of new rather than make_shared.

What's next?

Before I wrap up this post, I want to say a few remarks about my motivation for writing about modern C++ and in particular about the C++ Core Guidelines. During writing about my motivation, I recognized, that I can not express my motivation in few sentences. So you know what the next post will be about.