2025-10-07 (3 Lec): Semester Kickoff

Quiz

Project Management

Topic	Weak	Intermediate	Strong
CMake 2025-06-16 Nodes and dependencies 2025-06-16 Include paths
Git 2025-05-12 Git Basics 2025-05-20 Git remote workflow

C/C++

Topic	Weak	Intermediate	Strong
Interfaces and implementation Polymorphic types Interfaces
References, and const References
Constructors, Destructors

Linux

Topic	Weak	Intermediate	Strong
Shell usage (files and directories, permissions) 2025-04-28 (3 UE): The Shell, And The OS 2025-05-06 (3 UE): Shell/Permissions (Exercises)
System calls, file IO, processes, error handling
I2C
GPIO (libgpiod 👎)

Semester Plan

More Linux (Systems Programming)

Material

From Linux Systems Programming

• System Calls

• Files And File Descriptors

• Processes

• Signals

• Event Loops

Process Creation/Lifetime

Use case: blocking on sensor readout.

If, for example, a sensor takes 100ms to give the value that it measures, this might keep other parts of the software from reacting fast enough. It blocks the entire control program, leading to all sorts of misbehavior (e.g. motor stops too late)

Solution: create a subprocess which does the sensor readout. Communicate the value to the main/parent process.

Graceful Termination

When a process is requested to terminate (Ctrl-C on the console, or by kill-ing it), the process’s default behaviour is to just exhaust its life immediately. For a nontrivial control program, this might be too abrupt - it might want to do cleanup such as closing files (databases?), terminating child/worker processes, etc.

No Busy Loops

A tight polling loop of 1ms is not friendly. Lets save resources by doing nothing when there is nothing to do, and learn how to react intelligently on multiple event sources.

More C++

Ownership

Material

From C++ >= 11:

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

• The Rule Of Three/Five/Zero

This code from the main executable, run-door.cpp, has a number of shortcomings:

InputSwitchMock button1(InputSwitch::State::INPUT_LOW);
InputSwitchMock button2(InputSwitch::State::INPUT_LOW);
InputSwitchMock light1(InputSwitch::State::INPUT_LOW);
InputSwitchMock light2(InputSwitch::State::INPUT_HIGH);
MotorMock motor(Motor::Direction::IDLE);

Inputs inputs(&button1, &button2, &light1, &light2, time);
Outputs outputs(&motor);

• Inputs and Outputs get passed pointers to their delegees, and pointers are bad

• The lifetime of InputSwitchMock and MotorMock is automatic (on main’s stack frame). In less obvious code (the default) this can easily go wrong.

Lets decide on ownership semantics, and learn about C++11 smart pointers std::unique_ptr and std::shared_ptr. Also shed some light on ownership rules, and how C++ tries really hard to shoot you in the foot.

Bells and Whistles (Pythonicity)

Material

From C++ >= 11:

• Duck Typing (Err, auto) Without A Duck

• Local Variables In Control Flow Statements

• Tuple Unpacking (Err, Structured Binding)

• Range Based for Loops

• Lambda?

• Maybe (much) more

C++ is awful. C++11 (and onwards) tries to make it a better language (but fails). Learn about the funky new stuff.