Ada Byron’s code book

This “book” gathers a collection of C++ code snippets ready to be used as examples or reused in your own projects. The name Ada Byron in the repository title is a homage to the first software programmer (Wikipedia entry).

I use to build binaries for these settings (sorted alphabetically)

• Apple Mac OS X:
  • 10.11 El Capitan, Xcode 7.1.1 (LLVM, clang++) 64-bit (discontinued in January 2016)
  • 10.10 Yosemite, Xcode 6.2 (LLVM, clang++) 64-bit
• Linux Ubuntu: g++ 4.8.2, clang++ 3.4.1 (discontinued in October 2019)
• Microsoft Windows
  • 10 Pro:
    • Microsoft Visual Studio Community 2022 v17 (started in December 2021)
    • Microsoft Visual Studio Community 2019 v16
  • 8.1 Pro:
    • Microsoft Visual Studio Community 2015 v14 (started in July 2015; discontinued in October 2019)
    • Microsoft Visual Studio Community 2013 v12

and for all of them we use

• Boost Version 1.78.0 (December 8th, 2021 03:45 GMT)
• Boost Version 1.76.0 (April 16th, 2021 21:05 GMT)
• Boost Version 1.75.0 (December 11th, 2020 19:50 GMT)
• Boost Version 1.59.0 (August 13th, 2015 15:23 GMT)
• Boost Version 1.58.0 (April 17th, 2015 07:53 GMT)
• Boost Version 1.57.0 (November 3rd, 2014 21:55 GMT)

The “book” uses modern C++ features, and includes:

• Boost examples, using both just headers and installed components:
  • <boost/filesystem.hpp>, <boost/system/config.hpp>
  • casts (boost::lexical_cast, boost::numeric_cast)
  • <boost/algorithm/string.hpp> nice tools
  • XML parsing
• (TODO: Finish porting code from my Evernote’s notes)

Reference material

Some interesting URLs on different C++ revisions:

• C++ language revisions: Wikipedia’s C++23, C++20, C++17, C++14, C++11, C++03, and C++98 entries
• A cheatsheet of modern C++ language and library features, by Anthony Calandra
• Herb Sutter’s post on Elements of modern style
• Improved Type Inference in C++11
• Scott Meyers’s post on the Effective C++11 book
• Post on lambdas
• Alex Sinyakov’s C++11 cheat sheet
• Concurrency:
  • Bartosz Milewski’s post on Functional Data Structures and Concurrency in C++
  • cppreference.com’s thread
  • C++11 concurrency cheat sheet
  • Solarian Programmer’s C++11 multithreading tutorial (posted on December 16, 2011), C++11 multithreading tutorial - part 2, both with code on GitHub
  • K Hong’s Multi-Threaded Programming with C++11 - Part A, Part B (Sharing Data - mutex, and race conditions, and deadlock); Debugging - 2020

A never complete list of great C++ references (selected books, etc.):

• Scott Meyers, More Efficient C++: 35 New Ways to Improve Your Programs and Designs (mec++, for short), Addison-Wesley Professional Computing Series, 1996.
• Andrew Koenig, Barbara Moo, Ruminations on C++: A Decade of Programming Insight and Experience, Addison-Wesley, 1997. (I particularly love Chapter 4, Checklist for class authors.)
• Bjarne Stroustrup, The C++ Programming Language - Third Edition, Addison-Wesley, 1997.
• Anthony Williams, C++ Concurrency in Action: Practical Multithreading, Manning Publications, 2012.
• Wikibooks’ C++ programming subject, and category.
• Yurii Cherkasov’s The comprehensive catalog of C++ books- C++ links: Learning and teaching: A categorized list of C++ resources (a GitHub repo by MattPD).
• Modernes C++
• MITK’s Bug Squashing Seminars

A list of Boost-related stuff:

• Boris Schäling’s The Boost C++ Libraries
• Antony Polukhin’s Boost Application Development Cookbook Online Examples

Guidelines:

• A new open source project, led by Bjarne Stroustrup, on GitHub to build modern authoritative guidelines for writing C++ code: C++ Core Guidelines
• Herb Sutter, Andrei Alexandrescu, C++ Coding Standards: 101 Rules, Guidelines, and Best Practices, Addison Wesley Professional, 2004
• LLVM Coding Standards

C++ compilers:

• stroustrup.com/compilers.html, by Bjarne Stroustrup

A list of interesting libraries or toolkits:

• OpenGL Mathematics (GLM), a header only C++ mathematics library for graphics software

Some questions, and code:

• StackOverflow’s questions tagged C++
• C++ Code Examples from HotExamples

And finally, a list of good programming practices and other interesting programming books:

• Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts, Refactoring: Improving the Design of Existing Code, Addison Wesley, 2000

Code analysis

We strive to maintain a certain quality on the code by taking advantage of some tools:

• Cppcheck - A tool for static C/C++ code analysis. Being myself a fan of portable apps, I particularly use the version from PortableApps.com.
• “Analyze and Code Cleanup » Run Code Analysis on Only Ada-Byron-code-book” when using Microsoft Windows 10 Pro: Microsoft Visual Studio Community 2019 (Version 16)
• “Product » Analyze” when using Apple OS X: Xcode 7.1.1 (LLVM, clang++) 64-bit
• In g++ and clang++, address/thread/memory sanitizer (ASan, TSan, MSan)—for example, for ASan, with the flags -fsanitize=address -fno-omit-frame-pointer. See google/sanitizers repo.
• SonarLint, a Free and Open Source IDE extension that identifies and helps you fix quality and security issues as you code. Like a spell checker, SonarLint squiggles flaws and provides real-time feedback and clear remediation guidance to deliver clean code from the get-go.

Other tools related to code analysis:

• TODO (try this): C-Reduce “takes a large C or C++ program that has a property of interest (such as triggering a compiler bug) and automatically produces a much smaller C/C++ program that has the same property.”

Commits

When committing changes, we now favor using emojis that convey information (see, for example, gitmoji). In the past we used common prefixes—see for example a list of ITK changes. From the Slicer’s style guide:

Prefix	What
BUG	a change made to fix a runtime issue (crash, segmentation fault, exception, or incorrect result)
COMP	a fix for a compilation issue, error or warning
DOC	a documentation change
ENH	new functionality added to the project
PERF	a performance improvement
STYLE	a change that does not impact the logic or execution of the code (improve coding style, comments)

Example commit messages:

• Bad: BUG: Check pointer validity before dereferencing -> implementation detail, self-explanatory (by looking at the code)
• Good: BUG: Fix crash in Module X when clicking Apply button
• Bad: ENH: More work in qSlicerXModuleWidget -> more work is too vague, qSlicerXModuleWidget is too low level
• Good: ENH: Add float image outputs in module X
• Bad: COMP: Typo in cmake variable -> implementation detail, self-explanatory
• Good: COMP: Fix compilation error with Numpy on Visual Studio

Online compilers

• List at Get Started!
• Coliru
• Compiler Explorer (Godbolt)
• cppinsights.io
• The site <Coding Ground> includes a C++ online compiler
• Rextester
• Wandbox

Miscellaneous notes

Advice on unnecessary comments:

• Avoid (or remove) unnecessary comments! For example, from C++ Gotchas: Avoiding Common Problems in Coding and Design, by Stephen C. Dewhurst: Gotcha #1: Excessive Commenting: “If a maintainer has to be reminded of the meaning of the public: label [for example with the comment // Public Interface], you don’t want that person maintaining your code.”

Why C++ does not have a super keyword, and we do not promote creating any proxy for that:

• See the most voted answer of this StackOverflow’s thread.

Do not write (for example) using namespace std; in header files or before an #include:

• From Programming, Principles and Practice Using C++, by Stroustrup: “Be restrained in the use or using directives. The notational convenience offered by a using directive is achieved at the cost or potential name clashes. In particular, avoid using directives in header files.”
• From Thinking in C++, 2nd ed. Vol. 1, by Eckel: “Thus, if you start putting using directives in header files, it’s very easy to end up “turning off” namespaces practically everywhere, and thereby neutralizing the beneficial effects of namespaces. In short: don’t put using directives in header files.”
• From Industrial Strength C++, by Henricson and Nyquist: “A using declaration or a using directive in the global scope is not recommended inside header files, since it will make names globally accessible to all files that include that header.”
• From C++ Coding Standards: 101 Rules, Guidelines, and Best Practices, by Sutter and Alexandrescu: “Rule 59: Don’t write namespace #usings in a header file or before an #include.”

Advices on Hungarian notation, from well-known C++ gurus:

• “Notations that incorporate type information in variable names have mixed utility in type-unsafe languages (notably C), are possible but have no benefits (only drawbacks) in object-oriented languages, and are impossible in generic programming. Therefore, no C++ coding standard should require Hungarian notation, though a C++ coding standard might legitimately choose to ban it.” (from C++ Coding Standards: 101 Rules, Guidelines, and Best Practices, by Herb Sutter and Andrei Alexandrescu)
• “Additionally, never attempt to encode a variable’s type in its name. For instance, calling an integer index iIndex is actively damaging to understanding and maintaining the code. First, a name should describe a program entity’s abstract meaning, not how it’s implemented (data abstraction can apply even to predefined types). Second, in the common case that the variable’s type changes, just as common is that its name doesn’t change in sync. The variable’s name then becomes an effective source of misinformation about its type.” (from C++ Gotchas: Avoiding Common Problems in Coding and Design, by Stephen C. Dewhurst; Gotcha #8: Failure to Distinguish Access and Visibility)
• Examples: Ditch std::string sName; int iIndex; and write instead std::string name; int index;

---

Note: To render a GitHub (or Bitbucket) webpage containing code with a tab size of 2 spaces, append to its URL ?ts=2.