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 is 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 on the time line of C++ features makes my point clear.

If you look at the sheer amount of features we got since C++11 and reason about 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 these powerful feature changed the way we think about programming in C++? That is the not so simple quesion I want to answer.
Two resources
I'm not alone on 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. This general considerations include the safety, maintainability, portability, threadability, and performance of the code.
Today, I will not emphasise on the general considerations of the code, I will emphasise on 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 professional software developer - I guess you are because you read the post - and have to make a decision what tools you should use in your professional software development process you should use this great resource to get an idea what tools are available.
Today, I want to give you an idea 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 in major sections and supporting sections. Here are the major sections.
I want to have a closer look at the Introduction section. It deals with meta-rules such as:
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, nor enforce an impoverished subset of C++, nor 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 how the rule might be checked "mechanically"
- See alsos
- Notes
- Discussion
To be honest that strongly reminds me at the (design) pattern literature.
To make the intent of the structure clear, here is as short example the rule R.22. The R stands for resource management:
R.22: Use make_shared()
to make shared_ptr
s
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.
Thanks a lot to my Patreon Supporter: Eric Pederson.

Go to Leanpub/cpplibrary "What every professional C++ programmer should know about the C++ standard library". Get your e-book. Support my blog.
Comments
I'm sure they will be benefited from this site.
I will remember to bookmark your blog and will come
back someday. I want to encourage one to continue your great work, have a nice morning!
RSS feed for comments to this post