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++, which 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 revolution began 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 conclude: C++ before 2011 and since 2011 are different languages. The first is called classical C++, and the second modern C++. Therefore, the idiomatic way to program C++ before and after 2011 is 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 precious source for modern software development with C++ and general considerations of good C++ code. These general considerations include the code's safety, maintainability, portability, threadability, and performance.

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

His C++ Best Practices include 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 decide 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 following 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 rules aim to help developers adopt modern C++ (C++11, C++14, and soon C++17). These rules emphasize 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, and are not a substitute for tutorial treatment. The rules are either a guide to port old C++ code to new ones, nor should they be exact in each language detail, enforce an impoverished subset of C++, or are value-neutral or perfect. Each rule has an enforcement section because the guidelines should help people make their code uniform and modernize 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 also
• Notes 
• Discussion 

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++, particularly the C++ Core Guidelines. During writing about my motivation, I recognized that I could not express my motivation in a few sentences. So you know what the next post will be about.