C++: A Thorough Overview (2024-06-03)#

Day 1 #

Introduction: What C++ >= 11 Brings #

A Live-Hacked Tour Around The New C++ (the outcome of it being new-cpp.cpp
Duck Typing (Err, auto) Without A Duck, including
- a discussion of how arrays continue to decay to pointers in C++, using auto
- a demo of good old C decayed arrays, ptr-decay.cpp
Range Based for Loops: Introduction
Tuple Unpacking (Err, Structured Binding)
Lambda, and its relationship with std::function, std::function
- A little upside down show of it, lambda.cpp
- Walking through the inevitable capturing syntax, Lambda: More Capturing

Smart Pointers: `std::shared_ptr<>`, `std::unique_ptr<>` (And A Little `std::move`)#

From Smart Pointers: std::unique_ptr, std::shared_ptr (And std::weak_ptr):

Livecoding experiences:

Day 2 #

Morning Awakening #

mutable on lambda, to capture value by non-const copy: weak-ptr.cpp

Unit Testing, Test Driven Development, And `googletest`#

Relevant parts from Design Patterns and Test Driven Development (PDF)
From Unit Testing With googletest

A Little CMake #

From CMake (only what we use from it)

Exercise: `class Sensor`, And A `SensorConfig` Thereof #

Implementation detail: std::map
See tests directory in our Github project: jfasch/2024-06-03
- Working: tests/sensor-const-suite.cpp
- Working: tests/sensor-random-suite.cpp
- Not working: tests/sensor-config-suite.cpp. Does not even compile ⟶ commented-out in tests/CMakeLists.txt
Comment-in tests/sensor-config-suite.cpp
Add implementation files toolcase/sensor-config.h and toolcase/sensor-config.cpp, and fix until tests run.

Multithreading: Threads, Race Conditions, Locking Primitives #

From Multithreading, C++ Memory Model:

Threads Introduction
Threads in C++

Dissecting joinable vs. detached threads: join-vs-detach.cpp
std::atomic

i++ made thread safe with std::atomic<>: mother-of-race-conditions–atomic.cpp
std::mutex And Friends

i++ made thread safe with std::mutex (rather slow though): mother-of-race-conditions–mutex.cpp

Day 3 #

Exercise: Make `SensorConfig` Thread Safe #

Based upon the exercise from Day 2,

Implement new requirements from tests/sensor-config-suite.cpp
Make SensorConfig thread safe. Empirically check its thread safety by running tests/sensor-config-maybe-mt-safe.cpp

(See sensor-config.h and sensor-config.cpp)

Multithreading: Communication #

std::promise and std::future (And Some std::chrono) (Some Live Hacking)

See a contrived ping-pong game, livecoded in promise-future.cpp
std::condition_variable (Live Hacking Multithreaded Queue)

See an implementation of a thread safe queue, livecoded in thread-safe-queue.cpp

(A templated version of it available as queue.h)

Day 4 #

Exercise Time #

Group 1: Data Logger (Sketch)#

Given N Sensor instances in a SensorConfig, sketch a producer-consumer scenario over a Queue (the thread safe queue from queue.h),

N threads producing (timestamp, sensor_name, sensor_value) measurements into the queue.
One thread consuming those samples from the queue, and writing them to stdout as they arrive.

Group 2: Use `std::latch`#

Read the std::latch documentation
Given that communication device, and an understanding of it, write a program that pulls up a scenario that is just right for it. (“Construct a problem that fits the solution.”)

Group 3: Program a `MyLatch` Class #

Read the std::latch documentation, and make sense of it.
Write your own MyLatch implementation (presumably using a std::condition_variable and a std::mutex)

Outcome:

Implementation: my-latch.h
Test suite: latch-suite.cpp (note how futures can be used to achieve tests determinism)
Demo program: latch-demo.cpp

$ ./programs/latch-demo 1.2 3.6 0.1 7.5
producer #3 arriving
producer #1 arriving
producer #2 arriving
producer #4 arriving
consumer says "yessss, everybody arrived"

RValue References, Move Semantics #

Lvalues, Rvalues, And Moving
Lengthy livecoding: Rule Of 5?
Outcome string-move.cpp
Perfect Forwarding