The lifetime safety profile in the C++ core guidelines boils down to one issue: don’t dereference a possible invalid pointer. A pointer may be invalid because it is not initialized or the
nullptr. A pointer may also point beyond its rage or to a deleted object.
When you don’t dereference a possible invalid pointer, the impact on your program is, according to the C++ core guidelines manifold:
- eliminates one of the significant sources of nasty errors in C++
- eliminates a significant source of potential security violations
- improves performance by eliminating redundant “paranoia” checks
- increases confidence in the correctness of code
- avoids undefined behavior by enforcing an essential C++ language rule
Honestly, dealing with pointers is part of a bigger story: ownership. Ownership means that at each point in time, it must be evident who is responsible for managing the lifetime of an object. Roughly speaking, C++11 supports six kinds of ownership:
- Local objects. The C++ runtime, as the owner, automatically manages the lifetime of these resources. The same holds for global objects or members of a class. The guidelines call them scoped objects.
- References: I’m not the owner. I only borrowed the resource that cannot be empty.
- Raw pointers: I’m not the owner. I only borrowed the resource that can be can be empty. I must not delete the resource.
- std::unique_ptr: I’m the exclusive owner of the resource. I may explicitly release the resource.
- std::shared_ptr: I share the resource with another shared pointer. I may explicitly release my shared ownership.
- std::weak_ptr: I’m not the owner of the resource, but I may become temporary the shared owner of the resource by using the method std::weak_ptr::lock.
Compare this fine-grained ownership semantic with a raw pointer. Now you know what I like about modern C++.
You may ask yourself: Having rules is fine, but how can I check that my code follows these rules? Thanks to the Guidelines Support Library (GSL), the rules of the C++ core guidelines can automatically be checked.
Checking the Rules of the Guidelines
The GSL is a small library for supporting the C++ core guidelines. They are already a few implementations of the GSL available.
The GSL is a header-only library. Hence, you can use the functions and types of the library quite easily. The best-known implementation is the one from Microsoft, hosted at GitHub: Microsoft/GSL. The Microsoft version requires C++14 support and runs on various platforms. Here are a few quite popular platforms:
- Windows using Visual Studio 2015
- Windows using Visual Studio 2017
- Windows using Visual Studio 2019
- Windows using Clang/LLVM 3.6
- Windows using Clang/LLVM 7.0.0
- Windows using GCC 5.1
- Windows using Intel C++ Compiler 18.0
- GNU/Linux using Clang/LLVM 3.6-3.9
- GNU/Linux using Clang/LLVM 4.0
- GNU/Linux using Clang/LLVM 5.0
- GNU/Linux using Clang/LLVM 6.0
- GNU/Linux using Clang/LLVM 7.0
- GNU/Linux using GCC 5.1
Break of Type Safety, Bounds Safety, and Lifetime Safety
The comments in the source code document my issues. Let me start Visual Studio 2019 and show my steps to visualize the issues.
Enable Code Analysis on Build
Configure your Active Rules
As you can see from the screenshot, I create my ruleset CheckProfile, consisting of the C++ Core Guidelines Bounds Rules, C++ Core Guidelines Type Rules, and C++ Core Guidelines Lifetime Rules.
Run Code Analysis on Solution
Applying my set of rules to the code example was quite promising.
All issues are found. For each issue, such as the first one, I get the line number (17) and the rule of the affected profile (type.4).
Sometimes, you want to suppress specific warnings. You can achieve this with attributes. My following example applies two times an array to pointer decay. Only the second call should give a warning.
The attribute gsl::suppress(bounds.3) behaves as expected. It’s only valid in its scope. The second break of bounds safety is displayed.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, and Bhavith C Achar.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.
|My special thanks to Embarcadero|
|My special thanks to PVS-Studio|
|My special thanks to Tipi.build|
|My special thanks to Take Up Code|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,