The following notes are based on tutorials on LearnCpp.com. I take zero credit on any of the following contents except summarizing stuff here and there to fit them into one single post (barely). If you find it useful, please feel free to express your gratitude toward Alex and other authors of the original tutorial website.

Introduction / Getting Started

OK. This is a tediously long post but let’s start from the very basics.

Introduction to programming languages

A computer program is a set of instructions that the computer can perform. There are different levels of programming languages that a computer can run:

• Machine language: The limited set of instructions that a CPU can understand directly is called machine code (or machine language, or instruction set), which is composed of a sequence of binary digits (aka bits). Machine codes are usually not portable, namely, you have to rewrite them for every different system.
• Assembly language: To make machine language more readable, assembly language was invented with short abbreviations of instructions, and numbers are supported now. However, assembly language is still likely not portable. In order for CPU to understand the assembly language, the program must be translated to machine language by using an assembler.
• High-level language: To address the problem that programs are not generally portable across systems, there we have high-level programming languages, which must still be translated into a format the computer can understand. There are two ways in general:
  • Through a compiler, which is a program that reads source code and produces a standalone executable program that can then be run. Compilers can produce very fast and optimized code, sometimes faster than assembly language human writes. Another benefit of compiled programs is that distributing a compiled program does not require distributing the source code. In an non-open-source environment, this is important for IP protection purposes.
  • Through an interpreter, which is a program that directly executes the instructions in the source code without requiring them to be compiled into an executable first. Interpreters tend to be more flexible than compilers, but are less efficient when running programs because the interpreting process needs to be done every time the program is run. This also means the interpreter is needed every time the program is run.

Introduction to C/C++

The C language was developed in 1972 by Dennis Ritchie at Bell Lab. C ended up being so efficient and flexible that in 1973, Ritchie and Ken Thompson rewrite most of the Unix operating systems using C. In 1978, Brian Kernighan and Dennis Ritchie published the book The C Programming Language (later known as K&R) which provided an informal standard. In 1983, the American National Standards Institute (ANSI) formed a committee to establish a formal standard for C. They finished in 1989 with the C89 standard. In 1990, the International Organization for Standardization (ISO) adopted C89 and published C90, and later in 1999 the C99 standard.

C++ was developed by Bjarne Stroustrup at Bell Lab as an extension to C since 1979. C++ is mostly considered as a superset of C, but this is not strictly true as C99 introduced a few features that do not exist in C++. C++ was standardized in 1998 by the ISO and got a minor update in 2003, thereafter called C++03. Five major updates to the C++ language (C++11, C++14, C++17, C++20 and C++23) have been made since then, each adding new functionalities. C++11 in particular added a huge number of new capabilities and is widely considered to be the new baseline version of the language.

The underlying design philosophy of C/C++ can be summed up as “trust the programmer”, which is both wonderful and dangerous.

Compiler, linker and libraries

The compiler translates *.cpp to corresponding *.o object files. The linker combines all *.o object files, together with C++ Standard Library and other libraries, and then generates an executable file e.g. something.exe on Windows. This whole process is usually referred to as building. The specific executable produced as the result of building is sometimes called a build.

By combining softwares (editor, compiler, linker, debugger) involved in above steps into one, we have an integrated development environment (IDE).

C++ Basics

Preprocessor directive

The preprocessor directives are the include lines on top of source files e.g.

#include <iostream>

which here indicates that we would like to use the contents of the iostream library (which is the part of the C++ standard library that allows us to read and write text from/to the console).

Statements

A computer program is a sequence of instructions that tell the computer what to do. A statement is a type of instruction that causes the program to perform some action. Most (but not all) statements in C++ end in a semicolon. There are many different kinds of statements in C++:

• Declaration statements
• Jump statements
• Expression statements
• Compound statements
• Selection statements (conditionals)
• Iteration statements (loops)
• Try blocks

Functions and the main function

A function is a collection of statements that get executed sequentially (in order, from top to bottom). The name of a function is called its identifier.

Every C++ program must have a main function.

Comments

std::cout << "Hello world!">;  // this is a single-line comment
/* this is a multi-line
   comment in C++ */

Data, values, objects and variables

Data on a computer is typically stored in a format that is efficient for storage or processing (and is thus not human readable). A single piece of data is called a value. An object in C++ is a region of storage on RAM that can store a value, and has other associated properties. Although objects in C++ can be unnamed (anonymous), more often we name our objects using an identifier. An object with a name is called a variable.

Variable instantiation

We use a special kind of declaration statement called a definition to create a variable, e.g.

int x;

At compile-time, when the compiler sees this statement, it makes a note to itself that we are defining a variable named x of type int. Moving forward, whenever the compiler sees x, it knows that we’re referencing this variable. In C++, the type of a variable must be known at compile-time and cannot be changed without recompiling the whole program.

At runtime, the variable will be instantiated, which means the object will be created and assigned a memory address.

You can define multiple variables in either ways below:

int a;
int b;
// or
int a, b;

Variable Initialization

There are 6 basic ways to initialize a variable in C++:

int a;       // default initialization
int b = 5;   // copy initialization
int c(6);    // direct initialization
int d {7};   // direct list initialization
int e = {8}; // copy list initialization
int f {};    // empty list / value initialization

The modern way to initialize objects in C++ is to use a form of initialization that makes use of curly braces. Informally, this is called list initialization (or uniform initialization or brace initialization). List initialization has an added benefit besides providing a uniform interface (for both atomic and a list of values): it disallows narrowing conversions. This means that is you try to brace initialize a variable using a value that the variable can not safely hold, the compiler will produce an error instead of a warning or even worse, silently taking the valid part of the input:

int width = 4.5;   // warning: implicit conversion from 'double' to 'int' changes value from 4.5 to 4
int width { 4.5 }; // error: a number with a fractional value can't fit into an int

You can initialize multiple variables in the following ways (except the last one):

int a = 5, b = 6;
int a(5), b(6);
int a{5}, b{6};
int a = {5}, b = {6};
int a {}, b {};
int a, b(5);
int a, b{5};
int a, b = 5;  // error: a is not initialized!

Unused initialized variables warning

C++ will generate a warning is a variable is initialized but not used. For example:

int main() {
    int x { 5 };
    return 0;
}

When compiling the program above, the following warning is generated

main.cpp:2:9: warning: unused variable 'x' [-Wunused-variable]
    int x { 5 };
        ^
1 warning generated.

There are a few ways to fix this. First, if the variable is really unused, we can just remove its definition from the program. Second, we can use it somewhere e.g. cout << x. When neither are desirable solutions, in C++17 we have introduced a new [[maybe_unused]] attribute, which allows us to tell the compiler that we’re okay with these variables being unused.

int main() {
    [[maybe_unused]] int x { 5 };
    return 0;
}

Introduction to iostream: cout, cin and endl

We need to include iostream library so that we have access to std::cout etc. We can use std::cout with an insertion operator << to send the string to the console to be printed. Similarly, we can print a newline whenever a line of output is complete by using std::endl.

It’s good to know that std::cout is buffered, meaning that the slow transferring of a batch of data to an output device is optimized with a potential risk of not printing everything if the program crashes, aborts or is paused (e.g. for debugging) halfway before the buffer is flushed. Also, for the same underlying reason, using \n instead of std::endl is actually preferred for better performance, as the cursor is moved to the next line of console without flushing the buffer.

std::cout << "x is good" << std::endl; // this is slower than below
std::cout << "y is better\n";          // no flushing, just newline

Whereas std::cout uses an insertion operator <<, std::cin reads the input using an extraction operator >>. The input must be stored in a variable to be used later.

int x{};
std::cin >> x;

It’s (also) good to know that the C++ I/O library does not provide a way to capture keyboard input without the user pressing ENTER. In order to do that, one might need to resort to third-party libraries e.g. pdcurses, FXTUI, cpp-terminal or notcurses.

Let’s take a look at the following program

#include <iostream>

int main() {
    std::cout << "Enter a number: ";
    int x{};
    std::cin >> x;
    std::cout << "You entered " << x << '\n';
    return 0;
}

What happens when we enter

• 123: You entered 123

  Works fine.

• a: You entered 0

  Nothing to extract really. std::cin goes into failure mode and refused to pass anything to x (which by default is 0).

• 123.1: You entered 123

  This is because list initialization only disallows narrow conversion on the line of definition. The user’s input is processed and assigned to x on another line and thus conversion still can happen.

• -3: You entered -3

  Works fine for negative numbers as well.

• aaa: You entered 0

  Nothing to extract.

• a123: You entered 0

  Nothing to extract because the input is lead by character a.

• 123a: You entered 123

  Extracting everything until it can’t.

Uninitialized variables

In C++, leaving the variables uninitialized can be dangerous, so we need to know what will happen when e.g. an integer is defined yet uninitialized:

int globalVar;  // [GOOD] global variable is zero-initialized

void function() {
    static int staticVar;  // [GOOD] static variable is zero-initialized
}

int main() {
    int localVar1;  // [BAD] local variable is indeterminate when uninitialized
    std::cout << localVar1;  // [BAD] could be any value or lead to crash
    int localVar2{};  // [GOOD] local variable is zero-initialized w/ curly braces
    int array[5] = {42};  // [GOOD] unspecified array values are zero-initialized
}

Keywords (aka reserved words)

There are 92 keywords as of C++23, which all have special meanings in the C++ language:

C++ also defines special identifiers: override, final, import and module. These have special meanings when used in certain contexts but are not reserved otherwise.

Identifier naming best practices

• If the variable/function name is one word, the whole thing should be in lower case e.g.

  int value;
  int function();
  

• If the variable or function name is multi-word, both snake case and camel case are preferred.

  int some_value;      // snake case
  int some_function(); // snake case
  int someValue;       // camel case
  int someFunction();  // camel case
  

• Avoid naming identifiers starting with an underscore, as these are often reserved for OS, library and/or compiler use.

• Name your identifiers as meaningful as possible, except for those trivial variables serving as intermediate purposes.

Whitespace rules

• Whitespaces are used as separators in C++, but the compiler doesn’t care how many whitespaces are used.

• Sometimes newlines are used as separators e.g. in single-line comments and preprocessor directives (e.g. #include <iostream>).

• Quoted text takes whitespaces literally and do not allow newlines. Quoted text separated by nothing but whitespaces or newlines are automatically concatenated:

  std::cout << "this is not the same";
  std::cout << "this is not    the same";
  std::cout << "this is not
      allowed"; // broken by newline, not allowed
  std::cout << "this is "
      "allowed though";  // separated by whitespace
  

Basic coding style

• By converting tabs into spaces automatically, the formatting is self-describing – code that is spaced using spaces will always look correct regardless of editor. There is no right answer whether using tabs is better or worse than spaces though.

• The Google C++ style recommends putting the opening curly brace on the same line as the statement, the other commonly accepted alternative is to align the opening and closing braces on the same level of indentation.

• Each statement within curly braces should start one tab in from the opening brace.

• Lines should not be too long. Typically by “too long” we mean more than 80 characters.

• If a long line is split with an operator (e.g. << or +), the operator should be placed at the beginning of the next line, not the end of the current line:

  std::cout << 3 + 4
      + 5 + 6
      * 7 * 8;
  

• Use whitespaces to make your code easier to read by aligning values or comments or adding spacing between blocks of code:

  // 1A: hard to read:
  cost = 57;
  pricePerItem = 24;
  value = 5;
  numberOfItems = 17;
  
  
  // 1B: easier to read:
  cost          = 57;
  pricePerItem  = 24;
  value         = 5;
  numberOfItems = 17;
  
  
  // 2A: hard to read:
  std::cout << "Hello world!\n"; // cout lives in the iostream library
  std::cout << "It is very nice to meet you!\n"; // these comments make the code hard to read
  std::cout << "Yeah!\n"; // especially when lines are different lengths
  
  
  // 2B: easier to read:
  std::cout << "Hello world!\n";                  // cout lives in the iostream library
  std::cout << "It is very nice to meet you!\n";  // these comments are easier to read
  std::cout << "Yeah!\n";                         // especially when all lined up
  
  
  // 3A: hard to read:
  // cout lives in the iostream library
  std::cout << "Hello world!\n";
  // these comments make the code hard to read
  std::cout << "It is very nice to meet you!\n";
  // especially when all bunched together
  std::cout << "Yeah!\n";
  
  
  // 3B: easier to read:
  // cout lives in the iostream library
  std::cout << "Hello world!\n";
  
  // these comments are easier to read
  std::cout << "It is very nice to meet you!\n";
  
  // when separated by whitespace
  std::cout << "Yeah!\n";
  

Literals

Literals are values that are inserted directly into the source code. These values usually appear directly in the executable code (unless they are optimized out). In contrast, objects and variables represent memory locations that hold values and these values can be fetched on demand.

Operators

In mathematics, an operation is a process involving zero or more input values (called operands) that produce a new value (called an output value). The specific operation to be performed is denoted by a symbol usually, called an operator. This is the same as in C++. There are operators that are represented by symbols e.g. +, -, *, /, = and insertion <<, extraction >> and equality ==. There are also operators that are reserved words e.g. new, delete and throw.

The number of operands an operator takes as input is called the operator’s arity. Operators in C++ come in four different arities:

• Unary operators act on one operand e.g. negative - in -5.
• Binary operators act on two operands (often called left and right operands) e.g. addition + in 3 + 4, or insertion << as in std::cout << "something".
• Ternary operators act on three operands. There is only one ternary operator in C++, namely the conditional operator.
• Nullary operators act on zero operands. There is only one nullary operator in C++, namely the throw operator.

Note that some operators have different meanings depending on the use case e.g. operator - can mean both negative and subtract.

There is a famous abbreviation for the order in which the arithmetic operators are executed: PEMDAS (parenthesis > exponents > multiplication/division > addition/subtraction).

Functions and Files

Introduction to functions

The syntax/form of a general value-returning function is

return_type function_name() {
    // function body
    return return_value;
}

and for a non-value-returning functions

void function_name() {
    // function body
}

The C++ standard only defines the meaning of 3 status codes for programs: 0, EXIT_SUCCESS and EXIT_FAILURE. Both 0 and EXIT_SUCCESS mean the program executed successfully. EXIT_FAILURE means the program did not execute successfully.

#include <cstdlib>  // for EXIT_SUCCESS and EXIT_FAILURE

int main() {
    return EXIT_SUCCESS;
}

For maximum portability, we only use 0 or EXIT_SUCCESS to indicate a successful termination, and EXIT_FAILURE to indicate an unsuccessful termination. Function main will implicitly return 0 if no return statement is provided. That being said, the best practice is still to return a value from main explicitly.

C++ disallows calling the main function directly.

Function parameters and arguments

When a function is called, all its parameters of the functions, as defined in the function header, are created as variables, and the value of each of the arguments is copied into the matching parameter (using copy initialization). The process is called pass by value. Function parameters that utilized pass by value are called value parameters.

Local variables

Variables defined inside the body of a function are called local variables (as opposed to global variables), and they’re destroyed in the opposite order of creation at the end of the set of curly braces in which they are defined. The local scope is thereby defined as where a local variable’s lifetime lasts.

Forward declarations

The following program will throw a compile error

#include <iostream>

int main() {
    std::cout << "The sum of 3 and 4 is " << add(3, 4) << '\n';
    return 0;
}

int add(int x, int y) {
    return x + y;
}

because the C++ compiler compiles codes sequentially. By the time main uses add, the identifier add was even defined yet and thus causes a compile error complaining identifier not found. To address this problem, there are two options:

• Option 1: reorder the function definitions

  #include <iostream>
  
  int add(int x, int y) {
      return x + y;
  }
  
  int main() {
      std::cout << "The sum of 3 and 4 is " << add(3, 4) << '\n';
      return 0;
  }
  

• Option 2: use a forward declaration

  This is important as option 1 is not always possible, e.g. when function A calls function B within, and vice versa. That means we can never reorder them to allow sequential compiling.

  #include <iostream>
  
  int add(int x, int y);  // with or without parameter names, both are fine
  
  int main() {
      std::cout << "The sum of 3 and 4 is " << add(3, 4) << '\n';
      return 0;
  }
  
  int add(int x, int y) {
      return x + y;
  }
  

  It’s crutial to note that, if we forget to actually define the funciton body, the program will still compile just fine, but will eventuall fail at the link stage.

Declaration and definition

In C++, all definitions are declarations, but not always the other way around.

The one definition rule (ODR)

The one definition rule (aka ODR) is a well-known rule in C++, which consists of three parts:

• Within a file, each function, variable, type or template can only have one definition. Definitions occurring in different scopes do not violate this rule.
• Within a program, each function or variable can only have one definition. This rule exists because a program can have more than one files. Functions and variables not visible to the linker are excluded from this rule.
• Types, templates, inline functions and inline variables are allowed to have duplicate definitions in different files, so long as each definition is identical.

Violating the first part will issue a redefinition compile error. Violating part two will cause the linker to issue a redefinition error. Violating part three will cause undefined behavior.

Functions that share the same identifier but different sets of parameters are considered to be different functions, so won’t violate part one/two of ODR above.

Programs with multiple files

In order to write the following program (which will throw a compile error, see above) into a multi-file program

#include <iostream>

int main()
{
    std::cout << "The sum of 3 and 4 is: " << add(3, 4) << '\n';
    return 0;
}

int add(int x, int y)
{
    return x + y;
}

we might just write an app.cpp as

int add(int x, int y) {
    return x + y;
}

and main.cpp as

#include <iostream>

int main() {
    std::cout << "The sum of 3 and 4 is: " << add(3, 4) << '\n';
    return 0;
}

Naming collisions and namespaces

Most naming collisions occur in two ways:

• Two (or more) identically named functions (or global variables) are introduced into separate files belonging to the same program. This will result in a linker error.
• Two (or more) identically named functions (or global variables) are introduced into the same file. This will result in a compiler error.

C++ provides plenty of mechanisms for avoiding naming collisions. Besides local scope, we have namespaces:

• The global namespace (aka the global scope)
• The std namespace
• Other namespaces

There are two ways to use a namespace e.g. std:

• Explicit namespace qualifier :: e.g. std::cout
• Using namespace (not recommended) e.g. using namespace std;

Preprocessors

Preprocessors make various changes to the text of the code file, only after which the compilation happens. In modern compilers, the preprocessors are usually built right inside the compiler itself. Most of what the preprocessors do are fairly uninteresting, e.g. strips out comments, ensures each code file ends in a newline, and (most importantly) processing the #include directives.

Preprocessor directives

When the preprocessor runs, it scans through the code file (from top to bottom), looking for preprocessor directives. Preprocessor directives (often called directives) are instructions that start with a # symbol and end with a newline (NOT a semicolon). These directives tell the preprocessor to perform certain text manipulation tasks. Note that the preprocessor does not understand the C++ syntax – instead, the directives have their own syntax (which in some case resembles C++ syntax, and in other cases, not so much).

Below are some of the most common preprocessor directives:

• #include to include content of files

• #define to create global macros (in C++ a macro is a rule that defines how text is converted into replacement output text)

  There are two types of macros: object-like macros and function-like macros. The latter is usually considered unsafe, and almost anything they can do can be done by a normal function. The first, instead, can be used widely and in one of two ways:

  #define identifier
  #define identifier substitution_text
  

  Note that the substitution only happens in normal code, i.e. it does apply to other preprocessor directives.

  #define FOO 9 // Here's a macro substitution
  
  #ifdef FOO // This FOO does not get replaced because it’s part of another preprocessor directive
    std::cout << FOO << '\n'; // This FOO gets replaced with 9 because it's part of the normal code
  #endif
  

  We recommend avoiding the second kind of macros altogether at all, as there are better ways to do the same thing e.g. using named constants. For the first kind, they are accepted more generally.

• #ifdef, #ifndef and #endif for conditional compilation

  The conditional compilation preprocessor directives allow one to specify under what conditions something will or will not compile

  #include <iostream>
  
  #define PRINT_JOE
  
  int main() {
    #ifdef PRINT_JOE
        std::cout << "Joe\n";  // will be compiled
    #endif
  
    #ifdef PRINT_BOB
        std::cout << "Bob\n";  // will not be compiled at all
    #endif
  
    #ifndef PRINT_BOB
        #define PRINT_BOB  // will define PRINT_BOB
    #endif
  
    #ifdef PRINT_BOB
        std::cout << "Bob\n";  // will compile this time
    #endif
  
    return 0;
  }
  

• #if 0 can be used to exclude a block of code from being compiled as if it’s inside a comment block:

  #include <iostream>
  
  int main() {
    std::cout << "Joe\n";  // will be compiled
  
  #if 0
    std::cout << "Bob\n";  // will not be compiled at all
    /*
      this is some previously existing block comment and
      because of that, we cannot use block comment again
      to "comment out" this chunk of codes. using #if 0
      will be the only solution to avoid this part to be
      compiled or run by C++
    */
  #endif
  
  return 0;
  }
  

The scope of #define

The preprocessor doesn’t understand C++, so all preprocessor directives will be resolved before compilation from top to bottom on a file-by-file basis. The following macro MY_NAME, as a result, will be resolved without actually calling foo at all.

#include <iostream>

void foo() {
#define MY_NAME "Alex"
}

int main() {
 std::cout << "My name is: " << MY_NAME << '\n';
 return 0;
}

and the following code will print Not printing! because the directives are only valid from the point of definition to the end of the exact file.

function.cpp:

#include <iostream>

void doSomething() {
#ifdef PRINT
    std::cout << "Printing!\n";
#endif
#ifndef PRINT
    std::cout << "Not printing!\n";
#endif
}

main.cpp:

void doSomething(); // forward declaration for function doSomething()

#define PRINT

int main() {
    doSomething();
    return 0;
}

Header files

The main purpose of a header file (.h or .hpp) is to propagate declarations to code (.cpp) files. Source files (.cpp) should always include their own paired header files (.h or .hpp) if exist. No source files (.cpp) should be included, although C++ preprocessors are able to do that.

We use angled brackets <> for header files that are not written by ourselves. The preprocessor will search for the header only in the directories specified by the include directories. The include directories are configured as part of the project/IDE/compiler settings, and typically default to the directories containing the header files that come with your compiler and/or OS.

When we use double-quotes "" for the header file, we’re telling the preprocessor that the header file is written by us and should be first searched in the current directory. If it can’t find the file, it will then search the include directories.

When trying to include header files from another directory, you can, but are not recommended to do the following

#include "headers/myHeader.h"
#include "../moreHeaders/myOtherHeader.h"

Instead, it’s advised to change the IDE/compiler setting to include the extra include directories e.g.

g++ -o main -I/folder/other/headers main.cpp"

This is the same in VS Code, as you can add -I/folder/other/headers in the Args section in tasks.json of your project.

The #include order of headers

The best practice is to include headers in the following order:

• The paired header file
• Other headers from your project
• 3rd party library headers
• Standard library headers

The headers for each group should be sorted alphabetically unless documentation for a 3rd party library instructs you to do otherwise.

Header file best practices (summary)

• Always include header guards
• Do not define variables or functions inside header files – only declaration
• Give a header file the same name as the paired source file
• Each header file should have a specific job and be as independent as possible
• A header file should #include all other headers as long as needed so that it can function independently
• Only #include headers that we actually need
• Do not #include .cpp files
• Prefer putting documentation on
  • what something does or how to use it in the header as it’s more likely to be seen there
  • how something actually works in the source files

Header guards

The following project has header guards to prevent including duplicate definitions

square.h:

#ifndef SQUARE_H
#define SQUARE_H

int getSquareSides() {
    return 4;
}

#endif

wave.h:

#ifndef WAVE_H
#define WAVE_H

#include "square.h"

#endif

main.cpp:

#include "square.h"
#include "wave.h"

int main() {
    return 0;
}

However, if we add a source file square.cpp as follows, then the fact that square.h is included twice causes the problem of getSquareSides being defined once in square.cpp and main.cpp, causing a linker error:

square.cpp:

#include "square.h"

int getSquarePerimeter(int sideLength) {
    return sideLength * getSquareSides();
}

In order to solve this issue, we can put all definitions into source.cpp and leave only function declarations in square.h:

square.h:

#ifndef SQUARE_H
#define SQUARE_H

int getSquareSides();
int getSquarePerimeter();

#endif

square.cpp:

#include "square.h"

int getSquareSides() {
    return 4;
}

int getSquarePerimeter(int sideLength) {
    return sideLength * getSquareSides();
}

How about #pragma once

In modern compilers there is a simpler (but not as safe) way to do header guard:

#pragma once
// define whatever

Note: if a header file is copied so that it exists in multiple places on the file system, if somehow both copies of the header get included, header guards will successfully de-dupe the identical headers, but #pragma once won’t because the compiler won’t realize they are actually identical content.

Debugging C++ Programs

Debugging tactics

Several tips on debugging a C++ program:

• Conditionalizing the code using preprocessor directives e.g. ifdef, endif and define
• Using a logger e.g. plog, glog or spdlog
• Using an integrated debugger
  • Step into: run line by line inside function
  • Step over: run and skip the whole function
  • Step out: when you accidentally step into a function, use this to step out and pause on the next line of the function
  • Start: starting from the beginning
  • Continue: continue until the end
  • Breakpoints: tell debugger to stop no matter what
  • Variable watchers: monitoring the values of variables

Fundamental Data Types

Bits, bytes and memory addressing

The smallest unit of memory is a binary bit (aka a bit) which can hold 0 or 1. A modern de-facto standard byte is 8 bits.

Fundamental data types

Here is a list of fundamental data types in C++

The void type

There are three use cases of the void type:

• Functions that do not return anything

  void writeSomething(int x) {
    std::cout << x << '\n';
  }
  

• Functions that take no parameters (depreciated)

  int getValue(void) {
    return 0;
  }
  

  This is compilable in C++ (for backwards compatibility mostly) but not recommended. You can just remove the void in the brackets.

• Void pointers (advanced, covered later)

The sizeof function

See above table for the sizes in bytes of different fundamental data types. Notice that using of sizeof on incomplete type e.g. void will result in a compilation error. Also, sizeof don’t take dynamically allocated memory used by an object into consideration, about which we need to have further discussion.

On a side note, how fast a type is in C++ doesn’t really depend on how large the memory it uses. Instead of “smaller is faster”, CPUs are actually optimized w.r.t. the corresponding specs and thus seeing 32-bit int being faster than 16-bit short or an 8-bit char is totally possible on a 32-bit CPU.

Signed integer ranges

Again, in C++ only the minimum sizes of fundamental data types are specified, int and short starts with 2 bytes, long 4 bytes and long long 8 bytes. This means the actual size of the integers can vary based on implementation. The corresponding ranges of these types are listed below:

Assigning a value beyond the defined range will result in undefined behavior, which is called integer overflow.

Unsigned integer ranges

The corresponding range table for unsigned integer types are:

Unsigned integer overflow: if an unsigned value is out of range, is it divided by one greater than the largest number of the type, and only the remainder is kept. For example, the number 280 is too big for 1-byte integer, and thus 280 % 256 = 24 is set to the variable in the end.

Fixed-width integers, fast and least integers

Different from the native C/C++ integer types which have variable sizes (only minimum sizes were specified in above table), starting from C99 we have fixed-width integers in the stdint.h (later in C++ becoming cstdint.h) header:

#include <cstdint>
#include <iostream>

int main() {
  std::int16_t i{5};
  std::cout << i << '\n';
  return 0;
}

However, the fixed-width integers are not guaranteed to be defined on all architectures, nor is it faster than the native C/C++ integer types. This introduces the fast and least integer types:

#include <cstdint>
#include <iostream>

int main() {
  std::cout << "least 8: " << sizeof(std::int_least8_t) * 8 << "bits\n";
  std::cout << "least 16: " << sizeof(std::int_least16_t) * 8 << "bits\n";
  std::cout << "least 32: " << sizeof(std::int_least32_t) * 8 << "bits\n";
  std::cout << "fast 8: " << sizeof(std::int_fast8_t) * 8 << "bits\n";
  std::cout << "fast 16: " << sizeof(std::int_fast16_t) * 8 << "bits\n";
  std::cout << "fast 32: " << sizeof(std::int_fast32_t) * 8 << "bits\n";
  return 0;
}

where the least integer types guarantee that the integer holds at least given number of bits of width, and the fast integer types guarantee that the given integer type is the fastest with a width of at least given number of bits.

The downsides of these fast and least integers are that nobody really uses them and they might be too dynamic to make programs stable across architectures.

Best practice for integral types

Best practice:

• Prefer int when the size of the integer doesn’t matter
• Prefer std::int#_t when storing a quantity that needs a guaranteed range
• Prefer std::uint#_t when doing bit manipulation or where well-defined wrap-around behavior is required

Avoid the following if possible:

• short and long integers - use a fixed-width instead
• Unsigned types for holding quantities
• The 8-bit fixed-width integer types
• The fast and least fixed-width types
• Any compiler-specific fixed-width integers e.g. __int8 and __int16 in Visual Studio

What is std::size_t

The size of std::size_t is the upper limit of any object’s size in the system.

Floating point numbers

Remember to match the type of literal in initialization to the type of the variable, e.g.

int x{5};
double y{5.0};
float z{5.0F}; // notice the suffix `f`

When we print the floating point numbers, there are a few interesting behaviors that worth attention:

#include <iostream>

int main()
{
 std::cout << 5.0 << '\n';
 std::cout << 6.7F << '\n';
 std::cout << 9876543.21 << '\n';

 return 0;
}

The output of above program is

5
6.7
9.87654e+06

because

• std::cout by default doesn’t print the fractional part of a number if the fractional part is 0
• the number 6.7F was printed as expected because it’s defined as a short float that defaults to be printed full
• the scientific notation is used by default with 6 significant digits only

We can override the default precision that std::cout shows by default using an output manipulator function named std::setprecision():

#include <iomanip> // for output manipulator std::setprecision()
#include <iostream>

int main()
{
    std::cout << std::setprecision(17); // show 17 digits of precision
    std::cout << 3.33333333333333333333333333333333333333f <<'\n'; // f suffix means float
    std::cout << 3.33333333333333333333333333333333333333 << '\n'; // no suffix means double

    return 0;
}

which will now print

3.3333332538604736
3.3333333333333335

However, there’s a concept called rounding error that makes precision handling in floats a headache. See this example

#include <iomanip> // for std::setprecision()
#include <iostream>

int main()
{
    float f { 123456789.0f }; // f has 10 significant digits
    std::cout << std::setprecision(9); // to show 9 digits in f
    std::cout << f << '\n';

    return 0;
}

The output of the above program is 123456792 which is a totally different number, and that’s because the original number 123456789.0 has 10 significant digits. In order to show the original number with 9 significant digits only, the number cannot be stored exactly/precisely. A corollary of this is to be wary of using floating point numbers for financial or currency data.

The official ranges of floating point numbers are defined as below

NaN and infinity

There are two special categories of floating point numbers, NaN (not a number) and infinity.

#include <iostream>

int main()
{
    double zero {0.0};
    double posinf { 5.0 / zero }; // positive infinity
    std::cout << posinf << '\n';

    double neginf { -5.0 / zero }; // negative infinity
    std::cout << neginf << '\n';

    double nan { zero / zero }; // not a number (mathematically invalid)
    std::cout << nan << '\n';

    return 0;
}

The output of above program is

inf
-inf
nan

Best practice is to avoid using NaN or infinity at all.

Boolean values

bool b;
bool b1{true};
bool b2{false};
b1 = false;
bool b3{};  // default is false <- 0
bool b4{!true};  // initialized to false
bool b5{!false};  // initialized to true

Notice that printing boolean values is the same as printing the integer representation of the variables, i.e. only 0 and 1 will be printed. If you want std::cout to print actual true or false, you need to use another manipulator:

#include <iostream>

int main() {
    std::cout << true << '\n';
    std::cout << false << '\n';

    std::cout << std::boolalpha;  // from now on, true/false will be printed

    std::cout << true << '\n';
    std::cout << false << '\n';

    std::cout << std::noboolalpha;  // from now on, 1/0 will be printed

    std::cout << true << '\n';
    std::cout << false << '\n';
}

The conversion between a boolean and an integer variable is possible:

#include <iostream>

int main() {
    bool bFalse{0};  // ok
    bool bTrue{1};  // ok
    bool bNo{2};  // error (narrowing conversion is disallowed)
    bool b1 = 2;  // ok (copy initialization allows implicit conversion)
}

Inputting boolean values can be a bit unintuitive. See example below:

#include <iostream>

int main() {
    bool b{};
    std::cout << "Enter a boolean value: ";
    std::cin >> b;
    std::cout << "You entered " << b << '\n';
    return 0;
}

The output (if you typed true) is

Enter a Boolean value: true
You entered: 0

because std::cin only accepts either 0 or 1 for boolean variables, and thus the input true caused a silent fail in std::cin and thus the variable b never got assigned otherwise than its default value false. To allow std::cin to accept true and false, we need to again turn on the alphabetical mode of boolean variables by

#include <iostream>

int main() {
    bool b{};
    std::cout << "Enter a boolean value: ";
    std::cin >> std::boolalpha;
    std::cin >> b;
    std::cout << "You entered " << b << '\n';
    return 0;
}

Notice when std::boolalpha is enabled for std::cin, 0 and 1 will no longer work.

Chars

Some information worth noting:

• ASCII 0-31 are unprintable chars, 32 is   (space), 48 is 0, 65 is A and 97 is a.
• Multi-character input is allowed but only one character a time can be read into a char variable using std::cin. That means the subsequent std::cin can still read from the remaining input from the buffer.
• Escape sequences are listed below
  • \a: makes a beep alert
  • \b: moves the cursor back one space
  • \f: moves the cursor to the next logical page
  • \n: moves the cursor to next line
  • \r: moves the cursor to beginning of line
  • \t: prints a horizontal tab
  • \v: prints a vertical tab
  • \': prints a single quote
  • \": prints a double quote
  • \\: prints a backslash
  • \?: prints a question mark (no longer relevant, as you can now always use question marks)
  • \(number): prints a char represented by an octal number
  • \x(number): prints a char represented by a hex number

Implicit type conversion vs explicit static_cast

Implicit type conversion happens in the below program:

#include <iostream>

void print(int x) {
 std::cout << x << '\n';
}

int main() {
 print(5.5); // warning: we're passing in a double value

 return 0;
}

The output is 5 in this case, as an integer cannot hold fractional part. Brace initialization, on the other hand, doesn’t allow implicit conversion:

int main() {
    double d { 5 }; // okay: int to double is safe
    int x { 5.5 }; // error: double to int not safe
    return 0;
}

Explicit type conversion, in the same time, is supported via the static_cast operator:

#include <iostream>

void print(int x) {
 std::cout << x << '\n';
}

int main() {
 print( static_cast<int>(5.5) ); // explicitly convert double value 5.5 to an int
 return 0;
}

and the output is still 5 here as expected. It’s worth noting that by converting char into int we can effectively get the the ASCII code of a character:

#include <iostream>

int main() {
    char ch{97}; // 97 is ASCII code for 'a'
    std::cout << ch << " has value " << static_cast<int>(ch) << '\n';  // print value of variable ch as an int
    return 0;
}

where the output is

a has value 97

Meanwhile, by using static_cast to convert unsigned integer to signed integer variable, the compiler will produce undefined behavior and is definitely not recommended.

Constants and Strings

Two types of constants

C++ supports two different types of constants:

• Named constants are constant values that are associated with an identifier, aka symbolic constants
• Literal constants are constant values that are not associated with an identifier

Three types of named constants

There are three ways to define a named constant in C++:

• Constant variables (most common)
• Object-like macros with substitution text
• Enumerated constants (covered later)

In the first way, namely constant variables, please do remember that constant variables must be initialized. Parameters of a function can also be declared constant, but only necessary when passed by reference or pointer/address. When passed by value, a parameter doesn’t need to be declared constant to avoid the risk of being changed. Function return value can also be declared constant, but only when it’s not a fundamental type. For fundamental type return values, the const qualifier is ignored.

In the second way, we can define a constant via macro e.g.

#include <iostream>
#define MY_NAME "Allen"

int main() {
    std::cout << "My names is " << MY_NAME << '\n';
    return 0;
}

There are, however, at least three major reasons why people prefer the first method over using preprocessor macros:

• Macros don’t follow normal C++ scoping rules - once defined they’re there forever and cannot be replaced
• It’s harder to debug code with macros
• Macro substitution behaves differently than everything else in C++ and thus may cause inadvertent mistakes easily

Type qualifiers

We have known that const is a type qualifier. As a matter of fact, in C++ there are only two type qualifiers as of C++23, namely const and volatile. Latter is rarely used and is there to tell the compiler that an object may change its value at any time. This disables certain types of optimizations, in exchange.

The as-if rule

In C++, compilers are given a lot of leeway to optimize programs. The as-if rule says that the compiler can modify a program however it likes in order to optimize the performance. The only exception is that unnecessary calls to a copy constructor can be elided even if those copy constructors do have observable behavior.

For example, the following program can be optimized step by step:

Version 0 (original program):

#include <iostream>

int main() {
 int x { 3 + 4 };
 std::cout << x << '\n';
 return 0;
}

Version 1:

#include <iostream>

int main() {
 int x { 7 };
 std::cout << x << '\n';
 return 0;
}

Version 2:

#include <iostream>

int main() {
 std::cout << 7 << '\n';
 return 0;
}

Compile-time and runtime constants

Constants that are fixed at compile-time are called compile-time constants (like above). Constant variables that are only initialized at runtime are called runtime constants (see below).

#include <iostream>

int get_number() {
    std::cout << "Enter a number: ";
    int y{};
    std::cin >> y;
    return y;
}

int main() {
    const int x{3};  // x is compile-time constant
    const int y{get_number()};  // y is runtime constant
    const int z{x + y};  // z is runtime constant
    return 0;
}

Compile-time constants help optimization, but runtime constants are there just to keep the objects’ values are not changed.

The constexpr keyword

It’s sometimes hard to tell whether a variable will end up being compile-time constant or runtime constant, for example:

int x { 5 };       // not const at all
const int y { x }; // obviously a runtime const (since initializer is non-const)
const int z { 5 }; // obviously a compile-time const (since initializer is a constant expression)
const int w { getValue() }; // not obvious whether this is a runtime or compile-time const

Notice that, depending on how the function getValue is defined, w actually can be compile-time constant here - we have no idea, Fortunately, we can enlist the compiler’s help to ensure we get a compile-time constant when we desire so, simply by using the constexpr instead of const. When a variable is not compile-time constant yet we insist to use constexpr, there will be a compile error. As a result, the best practice is to use constexpr for any variable that should not be modifiable after initialization and whose initializer is known at compile-time.

There are, however, some types that are currently not compatible with constexpr keyword, including std::string, std::vector and other types that use dynamic memory allocation. For those objects we need to use const instead. Also, function parameters cannot be declared as constexpr as constexpr objects must be initialized with a compile-time constant.

Constant folding

Example 1:

#include <iostream>

int main() {
 constexpr int x { 3 + 4 }; // 3 + 4 is a constant expression
 std::cout << x << '\n';    // this is a runtime expression
 return 0;
}

Example 2:

#include <iostream>

int main() {
 std::cout << 3 + 4 << '\n'; // this is a runtime expression
 return 0;
}

In example 1 above, the variable x is a constant variable with its value initialized at compile-time, and as a result, the program will be optimized and consider x a compile-time constant. In example 2, 3 + 4 is not a constant expression, but because of an optimization process in C++ called constant folding, it’s still optimized at compile-time.

Literal suffixes

You may find lower-case suffixes accepted as well but they’re not recommended as lower-case l looks similar 1. Another thing to notice is that string literals in C++ are essentially C-style arrays of char with an extra null terminator. These C-style string literals are objects that are created at the start of the program and guaranteed to exist for the entirety of the program. In contrast, std::string and std::string_view create temporary objects that have to be used immediately, as they’re destroyed at the end of the full expression in which they’re created.

Magic numbers

Magic numbers are not recommended usually.

Numeral systems: decimal, binary, hexadecimal and octal

By default C++ integers are decimal numbers. Including decimals, there are 4 main numeral systems available in C++, which are decimal (base 10), binary (base 2), hexadecimal (base 16) and octal (base 8).

To use an octal literal, prefix the literal number with a 0 (zero):

#include <iostream>

int main() {
    int x{012};  // octal 12
    std::cout << x << '\n';
    return 0;
}

and the output would be 10, as numbers are output in decimal by default.

To use a hexadecimal literal, prefix your literal number with a 0x (zero x):

#include <iostream>

int main() {
    int x{0xF};  // hex F
    std::cout << x << '\n';
    return 0;
}

and the output would be 15. One digit of hexadecimal numbers represent 16=2^4 possible values, and thus two makes a full byte. A 32-bit integer, as a result, can be represented by eight hexadecimal digits concisely.

To use a binary literal, prefix your literal number with a 0b (zero b):

#include <iostream>

int main() {
    int x1{0b1};  // binary 1
    int x2{0b11110001};  // binary 11110001
    int x3{0b1111'0001};  // binary 11110001 with a quotation mark as visual separator
    std::cout << x1 << ' ' << x2 << ' ' << x3 << '\n';
    return 0;
}

and the output is 1 241 241. Notice how we used a single quotation mark as separator - this is also supported for other numeral systems e.g. a long decimal integer.

In order to print the values in other numeral systems than the current one, we can use std::dec, std::oct, std::hex manipulators:

#include <iostream>

int main() {
    int x{12};
    std::cout << x << '\n';  // default is dec
    std::cout << std::hex << x << '\n';  // now hex
    std::cout << x << '\n';  // still hex
    std::cout << std::oct << x << '\n';  // now oct
    std::cout << x << '\n';  // still oct
    std::cout << std::dec << x << '\n';  // now back to dec
    std::cout << x << '\n';  // still dec
    return 0;
}

As you may have guessed, outputting values in binary is a little harder than the rest three. We need to use a type called std::bitset in C++ STL (specifically, the <bitset> header) that gets the job done:

#include <bitset>
#include <iostream>

int main() {
    std::bitset<8> x1{ob1100'0101};  // an 8-digit binary number
    std::bitset<8> x2{oxC5};  // also 8-bit
    std::cout << x1 << ' ' << x2 << '\n';  // printing the variables
    std::cout << std::bitset<4>{0b1010} << '\n';  // printing a literal
    return 0;
}

There is an even better solution in C++20 and C++23, where we can use the <format> header and <print> header correspondingly:

#include <format>  // c++20
#include <iostream>
#include <print>  // c++23

int main() {
    std::cout << std::format("{:b}\n", 0b1010);  // c++20
    std::cout << std::format("{:#b}\n", 0b1010);  // c++20
    std::print("{:b} {:#b}", 0b1010, 0b1010);  // c++23
    return 0;
}

Conditional statement

The conditional statement is defined in the form condition ? statement1 : statement2. Remember to parenthesize the entire conditional statement to avoid unexpected behavior. Also, remember that statement1 and statement2 must match in types, namely the following won’t compile:

#include <iostream>

int main() {
    constexpr int x{5};
    std::cout << (x != 5 ? x : "x is 5") << '\n';
    return 0;
}

Inline functions and variables

Every time a function is called, there is a certain amount of performance overhead that occurs, specifically:

• The CPU must store the address of the current instruction it is executing (so that it knows where to return)
• The parameters must be instantiated and then initialized
• The execution path must then jump to the code in the function body
• Finally, the program need to jump back to the location of the function call and copy the return value to the main scope

This overhead is significant for small function with frequent calls. Fortunately, in C++ the compiler has a trick that can avoid such overhead: inline expansion. This is a process where a function call is replaced by the code from the called function’s definition. Inline expansion, however, doesn’t guarantee performance improvements as there’s a tradeoff between removal of the functional overhead vs the cost of a larger executable.

There used to be an inline keyword that suggests a function is inline for compilers. However, the keyword is no longer used and in fact:

• Using inline to request inline expansion might harm performance
• The inline keyword is now just a hint and the compilers simply ignore them now - they’ll decide whether to inline expand a function no matter if it has an inline keyword or not
• The inline keyword is defined at the wrong level of granularity, as the keyword goes with the function definition but the expansion actually happens only per function call

Inline variables, on the other hand, is a modern design of C++ that allows multiple definitions of the same variable identifier across multiple header files. The following, particularly, are implicitly inline:

• Functions defined inside a class, struct or union type definition (covered later)
• constexpr / consteval functions (covered later)
• Functions implicitly instantiated from function templates (covered later)
• constexpr static variables (but not constexpr non-static variables)

constexpr and consteval

Remember we can use constexpr variable to optimize programs for compile-time evaluation:

#include <iostream>

int main() {
    constexpr int x{5};
    constexpr int y{6};
    std::cout << (x > y ? x : y) << " is greater!\n";
    return 0;
}

However, if we replace the conditional statement by a function, the same program won’t enjoy the compile-time optimization and that means tradeoff of performance for modularity benefits. This isn’t ideal. We can instead declare functions as constexpr so that they can be evaluated at compile-time:

#include <iostream>

constexpr int greater(int x, int y) {
    return (x > y ? x : y);
}

int main() {
    constexpr int x{5};
    constexpr int y{6};
    constexpr int g{greater(x, y)};  // evaluated at compile-time
    std::cout << g << " is greater!\n";
    return 0;
}

It is worth noting that, despite the example above, constexpr doesn’t guarantee the compile-time evaluation, but instead just make the function eligible for compile-time evaluation. In the following example, because x and y are not constexpr, the function is still evaluated at runtime:

#include <iostream>

constexpr int greater(int x, int y) {
    return (x > y ? x : y);
}

int main() {
    int x{5};
    int y{6};
    std::cout << greater(x, y) << " is greater!\n";
    return 0;
}

Prior to C++20, there were no standard language tools available to test whether a function call is evaluating at compile-time or runtime. In C++20, std::is_constant_evaluated function defined in <type_traits> header gives a boolean indication whether the function call is executing in a constant context:

#include <type_traits>

constexpr int greater(int x, int y) {
    if (std::is_constant_evaluated()) {
        std::cout << "greater(" << x << ", " << y << ") is being"
                  << " evaluated at compile-time!\n";
    } else {
        std::cout << "greater(" << x << ", " << y << ") is being"
                  << " evaluated at runtime!\n";
    }
    return (x > y ? x : y);
}

In addition to testing, we can also force a function call to be evaluated at compile-time by ensuring the return value is used where a constant expression is required. This, however, need to be done on a per-call basis and thus can be seen tedious. In C++20, there is a better workaround to enforce this - consteval, which is used to indicated that a function must be evaluated at compile-time, otherwise a compile error will result. Such functions are called immediate functions. For example:

#include <iostream>

consteval int greater(int x, int y) {  // consteval! not constexpr
    return (x > y ? x : y);
}

int main() {
    constexpr int g {greater(5, 6)}; // evaluated at compile-time because return goes into constexpr
    std::cout << g << '\n';
    std::cout << greater(5, 6) << '\n';  // still at compile-time, guaranteed!
    int x{5};
    std::cout << greater(x, 6) << '\n';  // compile error!
    return 0;
}

The downside of consteval keyword is that it forces the function to be evaluated at compile-time, which in other words means the function can no longer be evaluated at runtime even if we want to. To solve this problem, we can define a helper function using abbreviated function template in C++20 and auto type (no need to fully understand at this stage)

#include <iostream>

consteval auto eval_at_compile_time(auto value) {  // consteval
    return value;
}

constexpr int greater(int x, int y) {  // constexpr
    return (x > y ? x : y);
}

int main() {
    std::cout << greater(5, 6) << '\n';  // runtime / compile-time -> we don't have full control
    std::cout << eval_at_compile_time(greater(5, 6)) << '\n'; // guaranteed compile-time
    int x{5};
    std::cout << greater(x, 6) << '\n';  // runtime, no error!
    return 0;
}

Input with std::string

#include <iostream>
#include <string>

int main() {
    std::cout << "Enter your full name: ";
    std::string name{};
    std::cin >> name; // this won't work as expected since std::cin breaks on whitespace
    std::cout << "Enter your favorite color: ";
    std::string color{};
    std::cin >> color;
    std::cout << "Your name is " << name << " and your favorite color is " << color << '\n';
    return 0;
}

The result from a sample run of the above program gives

Enter your full name: John Doe
Enter your favorite color: Your name is John and your favorite color is Doe

This is because std::cin breaks on whitespaces and thus John and Doe are separately passed to name and color strings. To remedy this issue, we need to use std::getline function:

#include <iostream>
#include <string>

int main() {
    std::cout << "Enter your full name: ";
    std::string name{};
    std::getline(std::cin >> std::ws, name); // read a full line
    std::cout << "Enter your favorite color: ";
    std::string color{};
    std::getline(std::cin >> std::ws, color);  // read a full line
    std::cout << "Your name is " << name << " and your favorite color is " << color << '\n';
    return 0;
}

and this time the output is

Enter your full name: John Doe
Enter your favorite color: blue
Your name is John Doe and your favorite color is blue

What is std::ws? It’s an input manipulator that tells std::cin to ignore any leading whitespace before extraction. Noticing that whitespace characters include spaces, tabs and newlines, we know the following program won’t work as expected:

#include <iostream>
#include <string>

int main() {
    std::cout << "Pick 1 or 2: ";
    int choice{};
    std::cin >> choice;

    std::cout << "Now enter your name: ";
    std::string name{};
    std::getline(std::cin, name); // note: no std::ws here

    std::cout << "Hello, " << name << ", you picked " << choice << '\n';

    return 0;
}

Pick 1 or 2: 2
Now enter your name: Hello, , you picked 2

as we entered only 2\n, where 2 was passed to choice and \n passed to the std::getline function. The function notices that there’s nothing before end of the line and thus passed empty string to name. The best practice is, therefore, to keep using std::ws for every std::getline.

The length of strings

To get the length of a std::string variable, we can

#include <iostream>
#include <string>

int main() {
    std::string name{ "Alex" };
    std::cout << name << " has " << name.length() << " characters\n";

    return 0;
}

Notice the return type is not a regular integer but unsigned integral of type size_t. If you want to use this integer for following computation, it’s best to convert the type right away:

int length { static_cast<int>(name.length()) };

In C++20, there’s an easier way to get size of strings in signed integral type:

#include <iostream>
#include <string>

int main() {
    std::string name{ "Alex" };
    std::cout << name << " has " << std::ssize(name) << " characters\n";
    return 0;
}

Initializing a std::string is expensive

…and thus don’t randomly initialize duplicate string variables, or pass them as values into functions. However, it’s okay to return a string by value when the expression of the return statement resolves to any of the following

• A local variable of type std::string
• A std::string that has been returned by value from a function call or operator
• A std::string that is created as part of the return statement

Because of scope and memory concerns. std::string may also be returned by (const) reference, which will be covered later.

To solve this problem, we have std::string_view (C++17). Instead of quickly copying e.g. a C-string to a new std::string and destroy it right away, we can create a readonly access to the original C-string and do whatever we want (as long as it’s readonly, like printing)

#include <iostream>
#include <string_view>

void print_string(std::string_view str) {
    std::cout << str << '\n';
}

int main() {
    std::string_view str{"Hello world"};
    print_string(str);
    return 0;
}

Note that implicit conversion from std::string_view to a std::string is not allowed and will give a compile error. However, explicitly initializing a std::string with a std::string_view is possible.

#include <iostream>
#include <string>
#include <string_view>

void print_string(std::string str) {
    std::cout << str << '\n';
}

int main() {
    std::string_view str{"Hello world"};
    print_string(str);  // will throw a compile error for implicit conversion
    std::string str2{str};  // okay: explicit initialization
    print_string(str2);  // okay
    print_string(static_cast<std::string>(str));  // okay: explicit conversion
    return 0;
}

Assignment, regardless whatever variable a std::string_view was originally viewing, makes it view another variable and that’s all. It doesn’t change anything and the content being viewed remains readonly.

Also, unlike std::string, std::string_view supports constexpr:

#include <iostream>
#include <string_view>

int main() {
    constexpr std::string_view s{ "Hello, world!" }; // s is a string symbolic constant
    std::cout << s << '\n'; // s will be replaced with "Hello, world!" at compile-time
    return 0;
}

That being said, it’s best to just use std::string_view as a readonly function parameter instead of general variable in most cases. Specifically, when the underlying object is destroyed, the viewer gives undefined behavior (so don’t return a std::string_view from function in most cases); when the underlying object is modified, the viewer is invalidated and again, may give undefined behavior (every time the underlying object is modified, you need to revalidate the viewer with an assignment).

Additionally, std::string_view can return substrings by .remove_prefix(#) and .remove_suffix(#) with # being the number of characters to remove from the view.

Operators

There are two important properties of operators:

• Precedence: how much priority an operator is given
• Associativity: given a chain of operators under the same priority, how should we evaluate them, left-to-right or right-to-left?

The following is an exhaustive list of operators with their precedence and associativity:

Remainder and exponent operators

The remainder operator in C++ is operator% which takes the sign of the first operand. The exponent operator is provided by the <cmath> header.

#include <iostream>
#include <cmath>

int main() {
    std::cout << 21 % 4 << '\n';
    std::cout << -21 % 4 << '\n';  // the remainder's sign follows that of the first operand
    std::cout << std::pow(3, 4) << '\n';
    return 0;
}

In order to avoid overflow, we sometimes can manually check the limit of the integral types:

#include <cassert>  // for assert
#include <cstdint>  // for std::int64_t
#include <limits>   // for std::numeric_limits
#include <iostream>

int main() {
    std::int64_t max_int64 = std::numeric_limits<std::int64_t>::max();
    std::int64_t min_int64 = std::numeric_limits<std::int64_t>::min();
    assert((10 > 9) && "assert message");  // just showing how assert() works
    std::cout << max_int64 << ' ' << min_int64 << '\n';
    return 0;
}

Increment/decrement operators

There are 4 increment/decrement operators

Best practice is to use the prefix versions most of the time as they are more performant (no copy) and less surprising (thus to cause bugs). For certain cases, avoiding increment/decrement operators is recommended even:

int x{1};
x + ++x

The above code evaluates as 2 + 2 in Visual Studio and GCC, but 1 + 2 in Clang. To avoid confusion and potential bugs, we should altogether just avoid such coding.

The comma operator

The comma operator works very differently as in Python, thus we’re paying extra attention to it. The formal definition of operation x,y is “evaluate x and then y, then return the value of y”. For example, the following code will print 3:

#include <iostream>

int main() {
    int x{1};
    int y{2};

    std::cout << (++x, ++y) << '\n';
    return 0;
}

Even worse, check these two lines:

z = (a, b);
z = a, b;

The first line is “evaluate a first, then evaluate b, and assign b to z”. The second line is “assign a to z, then evaluate b and discard it right away”.

As a result, the best practice is DON’T USE COMMA OPERATORS AT ALL.

Relational operators and floating point comparison

The first and third lines below are redundant and should be replaced by the second and last lines instead:

if (b1 == true) {};
if (b1) {};
if (b1 == false) {};
if (!b1) {};

The following will print d1 > d2 despite mathematically d1 and d2 are equal, and this is because of precision handling in floating points:

#include <iostream>

int main() {
    double d1{ 100.0 - 99.99 }; // should equal 0.01 mathematically
    double d2{ 10.0 - 9.99 }; // should equal 0.01 mathematically

    if (d1 == d2)
        std::cout << "d1 == d2" << '\n';
    else if (d1 > d2)
        std::cout << "d1 > d2" << '\n';
    else if (d1 < d2)
        std::cout << "d1 < d2" << '\n';

    return 0;
}

As a result, floating point comparison using relational operators can be dangerous sometimes. Instead of using these native operators, we can define our own “approximately equal” function:

// C++23 version -> so that std::abs is constexpr
#include <algorithm> // for std::max
#include <cmath>     // for std::abs (constexpr in C++23)

// Return true if the difference between a and b is within epsilon percent of the larger of a and b
constexpr bool approximatelyEqualRel(double a, double b, double relEpsilon) {
 return (std::abs(a - b) <= (std::max(std::abs(a), std::abs(b)) * relEpsilon));
}

// Return true if the difference between a and b is less than or equal to absEpsilon, or within relEpsilon percent of the larger of a and b
constexpr bool approximatelyEqualAbsRel(double a, double b, double absEpsilon, double relEpsilon) {
    // Check if the numbers are really close -- needed when comparing numbers near zero.
    if (std::abs(a - b) <= absEpsilon)
        return true;

    // Otherwise fall back to Knuth's algorithm
    return approximatelyEqualRel(a, b, relEpsilon);
}

With that, we can compare like this:

int main() {
    constexpr double a{ 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 };  // almost 1
    constexpr double relEps { 1e-8 };
    constexpr double absEps { 1e-12 };
    constexpr bool same { approximatelyEqualAbsRel(a, 1.0, absEps, relEps) };
    std::cout << same << '\n';
    return 0;
}

We’re using C++23 so that std::abs is constexpr, otherwise the compiler will throw an error when instantiating same. In that case, we can fix the above program by defining our own abs function.

Logical operators

There are three kinds of logical operators: logical NOT (!), logical OR || and logical AND &&. The latter two share a property called short circuit evaluation, which means the left operand, if determining the final result already, will terminate the evaluation early without the right operand being evaluated at all. If we overload these operators with our own function definitions, this short circuit behavior is gone.

Another thing worth noting is that && actually has high precedence than ||. As a result, when mixing && and ||, it’s best to use parentheses whenever possible.

Bit Manipulations

Bit flags and bit manipulation via std::bitset

When defining bit flags, we use std::bitset from <bitset> header:

#include <bitset>

std::bitset<8> mybitset {};  // 8 bits = 8 flags

The class std::bitset provides some key functions that are useful for bit manipulation:

test()  // query whether a bit is a 0 or 1
set()   // turn a bit on (this will do nothing if the bit is already on)
reset() // turn a bit off (same as above)
flip()  // flip a bit from 0 to 1 (or vice versa)
all()   // check if all are 1
any()   // check if any is 1
none()  // check if none is 1

Bitwise operators

C++ provides 6 bit manipulation operators, often called bitwise operators:

Of all operators above, we have a corresponding assignment version.

Scope, Duration and Linkage

User-defined namespaces

Imagine we have the project structure as below:

foo.cpp:

int do_something(int x, int y) {
    return x + y;
}

goo.cpp:

int do_something(int x, int y) {
    return x - y;
}

with these two files only, the project will compile just fine, as we’re not combining them together. Now, let’s say we have another file main.cpp:

#include <iostream>

int do_something(int, int);

int main() {
    std::cout << do_something(1, 2) << '\n';
    return 0;
}

We would get a linker error right away for defining the same function twice. Notice that this error doesn’t require the main to actually call the do_something function - in fact, simply by declaring the function in main.cpp cause the error. To resolve this issue (without renaming one of the two function definitions), we can define our own namespace:

foo.cpp:

namespace Foo {
    int do_something(int x, int y) {
        return x + y;
    }
}

goo.cpp:

namespace Goo {
    int do_something(int x, int y) {
        return x - y;
    }
}

We can, if needed, define nested namespaces in either of the following ways:

namespace Foo {
    namespace Goo {
        ...
    }
}

// or

namespace Foo::Goo {
    ...
}

When using the nested namespaces a lot, we can define namespace aliases like below:

namespace Temp = Foo::Goo;

Local variables and global variables

• Local variables have block scope: they’re in scope from definition to the end of the block
• Local variables have automatic storage duration: same as above
• Best practice is to define local variables in the smallest scope allowed

On the contrary:

• Global variables are defined outside all functions including main
• Global variables can be defined inside a global namespace
• Best practice is to define a global variable, if not constant, with a prefix g or g_

Internal linkage and internal variables

An identifier with internal linkage can be seen and used within a single translation unit, but it is not accessible from other translation units (that is, it is not exposed to other linkers). This means if two source files share the same linker, the identifiers with internal linkage will be treated as independent and thus not violating ODR for duplicate definitions.

To make a global variable internal (and thus making it an internal variable), we can use the keyword static. Notice that static is ignored for const global variables as they’re internal by default already.

There are typically two reasons to give an identifier internal linkage:

• There s an identifier we want to make sure isn’t accessible to other files
• To be pedantic about avoiding naming collisions

External linkage and external variables

An identifier with external linkage can be seen and used by other other files. In that sense, external variables are more “global” than global variables. Functions and non-constant global variables are external by default. Constant global variables can be defined as external using extern keyword.

Sharing global constants across files

Prior to C++17, the following is the best practice:

• Create a header file
• Inside the header file, define a namespace
• Inside the namespace, define all the constants (make sure they’re constexpr)
• #include the header to wherever you need those constants

Because constant global variables are by default internal, each .cpp file are actually going to have an independent copy of all these constants and header guards won’t stop this from happening. Changing any of these constants, therefore, will result in lengthy recompiling/rebuilding time for large projects. In addition, it can involve a large lump of memory every time a copy is needed.

Instead of above, we can

• Create a header file and corresponding cpp file
• Inside both files, define a namespace
• Inside the namespace of the header file, declare all the constants as extern const (using const instead of constexpr here because constexpr cannot be forward declared)
• Inside the namespace of the cpp file, define the constants

We can, after learning inline function and variables, define the constants as inline constexpr:

• Create a header file
• Inside the header file, define a namespace
• Inside the namespace, define all the constants as inline constexpr

Static local variables

We have covered what static global variable means, now let’s talk about static local variables. Using the static keyword on a local variable changes the duration from automatic duration (from definition to end of block) to static duration (from definition to explicit destroy) - just like a global variable. One of the most common use case of static local variables is unique ID generation:

int generate_unique_id() {
    static int s_item_id {0};
    return s_item_id++;  // make copy; inc original; return copy
}

Another use case is when you have a function that requires a constant caching that takes a lot of time to generate on the first time.

Scope, duration and linkage summary

One last time let’s go over these concepts:

• scope: where the identifier is accessible
• duration: birth to death of an identifier
• linkage: whether multiple declarations of an identifier refer to the same entity or not

In table format:

Unnamed and inline namespaces

We have a few different namespaces available:

• Global namespace: no need for any accessor ::
• Normal named namespace: need name accessor name::
• Unnamed namespace (aka anonymous namespace): anything defined inside an anonymous namespace is seen as “static”, that is, they can only be accessed, globally, within the current source file; no need for any accessor ::
• Inline namespace: overtaking the global namespace

Using inline namespaces allow us to “switch” easily between multiple versions of functions etc without changing the old code.

Control Flow and Error Handling

Categories of flow control statements

If conditions

Only thing that needs attention is the following example:

#include <iostream>

int main() {
    if (true)
        int x{5};
    else
        int x{6};
    std::cout << x << '\n';
    return 0;
}

The program above won’t compile because both definitions of x are within the conditional blocks and thus destroyed by std::cout needs it.

Null statements

A null statement is an expression with just a semicolon:

if (x > 10)
    ;

which is equivalent to

if (x > 10);

and thus can be dangerous, for example:

if (nuclear_code_activated());
    blow_up_the_world();

The world will be blown up no matter whether the button is pressed or not, because what’s actually going on in the example above is

if (nuclear_code_activated()) {
    ;
}
blow_up_the_world();

constexpr if statements

Check this example:

#include <iostream>

int main(){
    constexpr double g {9.8};
    if (g == 9.8) {
        std::cout << "gravity is noraml\n";
    } else {
        std::cout << "gravity is " << g << '\n';
    }
    return 0;
}

The above example will compile but the if statement is only evaluated at compile time, which is wasteful as g is constexpr. In C++17 we can optimize the flow using constexpr if statements:

#include <iostream>

int main() {
    constexpr double g {9.8};
    if constexpr (g == 9.8) {
        std::cout << "gravity is normal\n";
    } else {
        std::cout << "gravity is " << g << '\n';
    }
    return 0;
}

Modern compilers may or may not use a warning to advise such conversion of if statement for optimization purposes, and the may or may not automatically do the constexpr treatment for you. So when such optimization is required, it’s best to be explicit than letting the compiler to decide.

switch statements

A switch statement is nothing but a chain of if-else-if statements:

switch (statement) {
    case 1:
        ...
    case 2:
        ...

    ...
    default:
        ...
}

Notice that a switch statement is evaluated case by case sequentially and it won’t automatically break out of the switch block without explicitly using break or return. As a result, the best practice is to keep a break or return at all cases, and keep a default in the end. For example:

#include <iostream>

int main() {
    switch (2) {
    case 1: // Does not match
        std::cout << 1 << '\n'; // Skipped
    case 2: // Match!
        std::cout << 2 << '\n'; // Execution begins here
    case 3:
        std::cout << 3 << '\n'; // This is also executed
    case 4:
        std::cout << 4 << '\n'; // This is also executed
    default:
        std::cout << 5 << '\n'; // This is also executed
    }
    return 0;
}

This is called switch overflow (or fall-through). When fall-through happens, compilers usually give warnings as it’s usually not intentional. That being said, if it is indeed desired, we can use the [[fallthrough]] attribute to indicate the compiler that a warning won’t be necessary:

#include <iostream>

int main() {
    switch (2) {
        case 1:
            std::cout << 1 << '\n';
            break;
        case 2:
            std::cout << 2 << '\n';
            [[fallthrough]];  // fall through starting from here
        case 3:
            std::cout << 3 << '\n';
            break;
    }
    return 0;
}

Sequential case labels

Because case labels are not statements (they’re labels), we can stack them if desired:

bool is_vowel(char c) {
    return (c == 'a' || c == 'e' || c == 'i' || c =='o' || c == 'u' ||
        c == 'A' || c == 'E' || c == 'I' || c == 'O' || c == 'U');
}

The above can be rewritten using switch statement as

bool is_vowel(char c) {
    switch (c) {
        case 'a':
        case 'e':
        case 'i':
        case 'o':
        case 'u':
        case 'A':
        case 'E':
        case 'I':
        case 'O':
        case 'U':
            return true;
        default:
            return false;
    }
}

This is not fall-through because only one case is being evaluated and executed.

switch case scoping

It’s worth noting that different from if statements where there’s an implicit block, under switch cases there’re not individual blocks. Instead, all cases share the same switch block:

switch (1) {
    int a;      // okay: definition is allowed before the case labels
    int b{ 5 }; // illegal: initialization is not allowed before the case labels

    case 1:
        int y; // okay but bad practice: definition is allowed within a case
        y = 4; // okay: assignment is allowed
        break;

    case 2:
        int z{ 4 }; // illegal: initialization is not allowed if subsequent cases exist
        y = 5;      // okay: y was declared above, so we can use it here too
        break;

    case 3: { // note addition of explicit block here
            int x{ 4 }; // okay, variables can be initialized inside a block inside a case
            std::cout << x;
            break;
        }
}

while and do-while statements

Skipped.

for loops

The general template is

for (init-statement; condition; end-expression) {
    statement;
}

which can be very confusing if we allow null statements:

for (;;) {
    statement;
}

The above is equivalent to

while (true) {
    statement;
}

A for loop can also have multiple variables in the init-statement:

for (int x{0}, y{10}; x < 10; ++x, --y) {
    std::cout << x << ' ' << y << '\n';
}

break, continue and early return

Skipped.

Halts

In <cstdlib> we have std::exit and std::atexit defined. std::exit terminates the program with the given exit status code. It also performs a number of cleanup functions:

• objects with static storage duration are destroyed
• file cleanup if files are used in the program
• return the control back to the OS with the status code

However, std::exit doesn’t clean up any local variables, and because of that, it’s advised to avoid std::exit generally. If we really need to use std::exit and have concerns like such, we can use std::atexit to register our own custom cleanup functions before calling std::exit.

For multi-threaded programs, calling std::exit in a subprocess can crash the main program because of destroyed static objects. To remedy this problem, C++ has provided another pair of halting functions that doesn’t clean up the static objects: std::quick_exit and std::at_quick_exit.

In addition, C++ has provided std::abort for abnormal termination, and std::terminate for exception handling. Notice that std::terminate actually calls std::abort implicitly.

std::cout vs std::cerr

We know that std::cout is buffered. This means the output may or may not be printed to console by the time the program crashes (if ever). In contrast, std::cerr is unbuffered and thus can always print the needed error message to console.

Clearing buffer in std::cin

We can simply

std::cin.ignore(100, '\n');

which ignores the following 100 characters in the buffer until and including the next ‘\n’. Even better, we can just ignore the maximum allowed length of stream:

#include <limits>

void ignore_line() {
    std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
}

The failure mode of std::cin

When an input is invalid and extraction fails, the wrong input is kept in the buffer and std::cin enters the failure mode. In order to continue input, we need to

if (std::cin.fail()) {
    std::cin.clear();
    ignore_line();
}

Because std::cin has an automatic boolean conversion indicating whether the last input succeeded, we can also

if (!std::cin) {
    std::cin.clear();
    ignore_line();
}

One last corner case is when end-of-file (EOF) character (via ctrl-D) is passed, the whole input stream closes. This is something that can’t be fixed by std::cin.clear() and thus we need to modify the above resetting logic to

if (!std::cin) {
    if (std::cin.eof()) {
        exit(0);  // we can just shut down the program
    }
    std::cin.clear();  // back to normal input stream
    ignore_line();     // ignore bad characters remaining in the buffer
}

It’s worth noting that when the user input overflows the range of target variable, e.g. passing 40,000 to int16 (whose range is -32,768 to 32,767), the assignment still happens:

• The closest limit is assigned to the value
• The input stream goes into failure mode

assert and static_assert

In C++, runtime assertions are implemented via the assert preprocessor macro, which lives in the <cassert> header:

#include <cassert>  // for assert
#include <cmath>    // for std::sqrt
#include <iostream>

double f(double x, double y) {
    assert(y > 0);
    if (x <= 0)
        return 0;
    return std::sqrt(2 * x / y);
}

int main() {
    std::cout << "The answer is " << f(100, -9) << '\n';
    return 0;
}

We can make our assertion statement more descriptive by adding a followup string to it

assert(condition && "my assert message");

This is because the logical AND (&&) operator has short circuit property and thus any false condition would yield the whole compound statement inside the parenthesis and thus including the added string literal in the error message.

It’s worth noting that assert macro comes with a small performance cost at each time the condition is checked, and thus in production code it’s usually advised to not use assert at all, as your code should be fully tested already. We can use the NDEBUG macro to turn off assert statements in some IDEs.

C++ also has another type of assertion called static_assert. This is basically the compile-time version of the assert which is runtime. Unlike assert which is a macro defined in <cassert>, static_assert is actually a keyword and thus no header is needed. A static_assert takes the following form:

static_assert(condition, message);

where the condition must be constant expression, and if any error, it would be a compiler error. Prior to C++17, the message used to be required, but this is no longer the case.

Generating random numbers

Using Mersenne Twister:

#include <iostream>
#include <random>   // for std::mt19937

int main() {
    std::mt19937 mt{}; // instantiate a 32-bit Mersenne Twister
    for (int count{1}; count <= 40; ++count) {
        std::cout << mt() << '\t';
        if (count % 5 == 0)
            std::cout << '\n';
    }
    return 0;
}

which will print 40 32-bit PRNG as a 8x5 table.

We can also generate uniform distribution:

#include <iostream>
#include <random>

int main() {
    std::mt19937 mt{};
    std::uniform_int_distribution die6{1, 6};
    for (int count{1}; count <= 40; ++count) {
        std::cout << die6(mt) << '\t';
        if (count % 10 == 0) std::cout << '\n';
    }
    return 0;
}

We can seed the random number generator as mt{42} instead of the default seed mt{1}, but more preferably we can use the std::random_device{} to achieve better pseudo-randomness:

#include <iostream>
#include <random>

int main() {
    std::mt19937 mt{ std::random_device{}() };
    // other following code
    return 0;
}

Notice that random_device only gives 32-bit (4 bytes) integer to seed the Mersenne number, but the random number generator is 624 bytes in size (156 folds of the size given). This means we’re effectively underseeding the generator, potentially making the result less random. To cope with that we can use std::seed_seq which basically combines a sequence of seed numbers, each of 4 bytes, into a large seeding object to be passed to the generator:

#include <iostream>
#include <random>

int main() {
    std::random_device rd{}; // just device, not called yet
    std::seed_seq ss { rd(), rd(), rd(), rd(), rd(), rd(), rd() };  // you can go all the way to 156 of rd() if you want
    std::mt19937 mt{ss};
    std::uniform_int_distribution die6{1, 6};
    for (int count{1}; count <= 40; ++count) {
        std::cout << die6(mt) << '\t';
        if (count % 10 == 0) std::cout << '\n';
    }
    return 0;
}

Type Conversion and Function Overloading

Implicit type conversion

Implicit type conversion happens in all of the following case:

When initializing a variable with a value of a different type:

double d {3}; // int converted to double
d = 6;  // int converted to double

When the type of a return value is different from the function’s declared return type:

float something() {
    return 3.0; // double 3.0 converted to float
}

When using certain binary operators with operands of different types:

double division {4.0 / 3};  // int 3 converted to double

When an argument passed to a function is a different type than the function parameter:

void something(long l) {
}

something (3);  // int 3 converted to long