Based on the video, here is a list of all the tools, libraries, and features that are used, added to, or used along with the cpp_starter_project:

Build & Configuration Tools:

• CMake
• CTest
• Conan (package manager)
• CCache

Code Quality & Formatting Tools:

• clang-format
• cmake-format
• clang-tidy
• CPPCheck

Compilers & Sanitizers:

• GCC / Clang / MSVC support
• Address Sanitizer
• Undefined Behavior Sanitizer
• Thread Sanitizer
• Fuzzing Sanitizer (libFuzzer from Clang/LLVM)

Libraries (managed via Conan):

• Catch2 (testing framework)
• docopt (command-line option parsing)
• fmt (formatting library, now partly in C++20)
• spdlog (fast logging)
• imgui-sfml (for IMGUI example)
• SFML (pulled in by imgui-sfml)
• SDL (for SDL example)

Documentation:

• Doxygen

Example GUI Libraries Shown:

• Qt
• FLTK
• GTKMM
• IMGUI
• NANA
• SDL

Editors/IDEs Mentioned:

• Neovim (with Neoformat plugin)

Other Features:

• Inter-procedural optimization (IPO) / Link Time Optimization (LTO)
• Precompiled headers (PCH)
• compile_commands.json generation (for clang tooling)
• Warnings as errors (-Werror / /WX)

Compiled it in Linux WSL

Here Mike explained the steps very well through his youtube video “ Build Clang++20 (LLVM 18 and lldb) from source”

And the guide in the Clang website is surprisingly good to get started LLVM - Getting Started: Building and Running Clang

Here is the continuation of the last post.

This time I try using Concepts to iterate through a bunch of “Sensors”. Here I use the generic function process_sensors that utilizes C++ Template Metaprogramming and uses the Ellipsis “…” operator to process through an arbritary amount of sensors (in this case, 3). The result is an expressive and elegant code (feels like I’m coding in javascript with the Spread Operator haha).

The measurements array stores results of read() of each sensors, invoked each time this process_sensors gets called. Fun fact, here the std::array automatically deduces it’s own type and size because of Class Template Argument Deduction (CTAD) enforced by the SensorLike concept (no need to define std::array<type, size>).

Is it the most efficient in the case when we need to optimize for firmware size, probably not. Is it fun? Yesh

Check it out!

github.com/royyandzakiy/zephyr-modern-cpp

// --- Concepts & Constraints ---
template <typename T>
concept SensorLike = requires(T t) {
	{ t.read() } -> std::convertible_to<int32_t>;
	{ t.get_id() } -> std::convertible_to<int>;
};

// --- Sensor Concepts Implementation ---
class TemperatureSensor {
  public:
	auto read() const -> int32_t {
		return 2350 + (sys_rand32_get() % 100); // 23.50 – 24.49
	}
	auto get_id() const -> int {
		return 1;
	}
};

class HumiditySensor {
  public:
	auto read() const -> int32_t {
		return 4500 + (sys_rand32_get() % 200); // 45.00 – 46.99
	}
	auto get_id() const -> int {
		return 2;
	}
};

class PressureSensor {
  public:
	auto read() const -> int32_t {
		return 101325 + (sys_rand32_get() % 500); // 1013.25+
	}
	auto get_id() const -> int {
		return 3;
	}
};

class StateMachine {
    // ...
    template <SensorLike... Sensors> auto process_sensors(Sensors &&...sensors) -> void {
		const std::array measurements{sensors.read()...};
		int temperatureSensorIdx = 0;

		// all sensor logic
		{
			int sensorIdx = 0;
			(
				[&]<typename T>(T &sensor) {
					const char *label = "Unknown";
					if constexpr (std::is_same_v<T, TemperatureSensor>) {
						label = "Temp";
						temperatureSensorIdx = sensorIdx;
					}
					if constexpr (std::is_same_v<T, HumiditySensor>)
						label = "Humid";
					if constexpr (std::is_same_v<T, PressureSensor>)
						label = "Press";

					LOG_INF("Sensor: %s | Value: %d", label, measurements[sensorIdx++]);
				}(sensors),
				...);
		}

		// TemperatureSensor value will cause system State change
		{
			const int32_t latest_temp = measurements[0];
			const size_t stored_count = std::min(buffer_index_, temp_data_circbuf_.size());

			// Update circular buffer
			temp_data_circbuf_[buffer_index_ % temp_data_circbuf_.size()] = latest_temp;
			buffer_index_++;

			std::visit(
				[this, latest_temp, stored_count]<typename Traw>(Traw &state) {
					using T = std::decay_t<Traw>; // cleanup any const/refs

					// this way, enforcement to ensure all Variant types are covered by the compiler becomes optional
					// (else, via static_assert). if I ommit the else, we can have a non-exhaustive "state machine"
					if constexpr (std::is_same_v<T, IdleState>) {
						if (latest_temp > TEMP_THRESHOLD_START_MONITORING) {
							transition_to(MonitoringState{latest_temp, 1});
						}
					} else if constexpr (std::is_same_v<T, MonitoringState>) {
						state.sample_count++;

						auto sum =
							std::accumulate(temp_data_circbuf_.begin(), temp_data_circbuf_.begin() + stored_count, 0LL);

						state.average_temp_value = static_cast<int32_t>(sum / stored_count);

						if (state.average_temp_value > TEMP_THRESHOLD_ALERT) {
							transition_to(AlertState{"Temperature High"sv, TEMP_THRESHOLD_ALERT});
						}
					} else if constexpr (std::is_same_v<T, AlertState>) {
						if (latest_temp < TEMP_THRESHOLD_RECOVERY) {
							transition_to(CalibratingState{CALIBRATION_REFERENCE_TEMP, 1});
						}
					} else if constexpr (std::is_same_v<T, CalibratingState>) {
						if (++state.calibration_step > MAX_CALIBRATION_STEPS) {
							transition_to(IdleState{});
						}
					} else if constexpr (std::is_same_v<T, std::monostate>) {
						transition_to(IdleState{});
					} else {
						// C++23: If a new state is added to StateVariant but not handled yet, force compile error
						static_assert(uncovered_type_exists<T>,
									  "Non-exhaustive visitor: You forgot to handle a state!");
					}
				},
				current_state_);
		}
	}
};

auto main() -> int {
    StateMachine sm_;
	TemperatureSensor t_;
	HumiditySensor h_;
	PressureSensor p_;

    sm_.process_sensors(t_, h_, p_);

    return 0;
}

I’ve been testing out to use it on Zephyr and ESP-IDF

One particular feature I tried out in this example is the use of std::variant for different States, and ultimately using std::visit to iterate through them. Here I provide implementation of a general get_state_info to read what the current state is using the Overloaded Lambda idiom (to enforce availability of all StateVariants), it will then return a std::string_view of different messages based on the current_state_

Let’s say, a more shiny Statemachine haha. A different approach than using bare enums and switch statements (not simply saying they are less)

Check it out here!

github.com/royyandzakiy/zephyr-modern-cpp

enum class StateId {
	IDLE,
	MONITORING,
	ALERT,
	CALIBRATING
};
struct IdleState {};
struct MonitoringState {
	int32_t average_temp_value;
	int sample_count;
};

struct AlertState {
	std::string_view message;
	int32_t threshold_temp_value;
};

struct CalibratingState {
	int32_t reference_temp_value;
	int calibration_step;
};

using StateVariant = std::variant<std::monostate, IdleState, MonitoringState, AlertState, CalibratingState>;

class StateMachine {
    // ...
    auto get_state_info() const -> std::string_view {
		return std::visit(Overloaded{
			[this](const IdleState&) -> std::string_view {
				return "Status: Idle - Awaiting for sensor trigger"sv;
			},
			[this](const MonitoringState& s) -> std::string_view {
				// psst: not using std::format because the zephyr SDK does not have #include <format>
				int len = snprintf(format_buffer_.data(), format_buffer_.size(), 
									"Status: Monitoring [Avg: %d.%02d°C | Samples: %d]",
									ipart(s.average_temp_value), fpart(s.average_temp_value), s.sample_count);
				return { format_buffer_.data(), static_cast<size_t>(len) };
			},
			[this](const AlertState& s) -> std::string_view {
				int len = snprintf(format_buffer_.data(), format_buffer_.size(), 
								"Status: ALERT [%.*s | Threshold: %d.%02d°C]", 
								static_cast<int>(s.message.length()), s.message.data(),
								ipart(s.threshold_temp_value), fpart(s.threshold_temp_value));
				return {format_buffer_.data(), static_cast<size_t>(len)};
			},
			[this](const CalibratingState& s) -> std::string_view {
				int len = snprintf(format_buffer_.data(), format_buffer_.size(), 
								"Status: Calibrating [Ref: %d.%02d°C | Step: %d/5]", 
								ipart(s.reference_temp_value), fpart(s.reference_temp_value), s.calibration_step);
				return {format_buffer_.data(), static_cast<size_t>(len)};
			},
			[this](const auto&) -> std::string_view {
				// default fallback
				return "Status: Unknown State! [Error]"sv;
			}
		}, current_state_);
	}
    // ...
};

auto main() -> int {
    StateMachine sm_;
	TemperatureSensor t_;
	HumiditySensor h_;
	PressureSensor p_;
    
    sm_.process_sensors(t_, h_, p_);

    // ...

    auto info = sm_.get_state_info();

    return 0;
}

So here is a cool “Perfect Forwarding” Hello, World! code implementation using C++. When std::string{"World!"} is passed, this is a prvalue (a “temporary”) aka an rvalue expression. T is deduced to std::string, becoming say_hello(std::string && name_param). In the other case, when instead the variable name is passed, this is a variable aka an lvalue, T is deduced to std::string& becoming say_hello(std::string& && name_param), the && will get reduced (reference collapsing rules), therefore finally becoming say_hello(std::string& name_param).

std::forward<T> restores the value category (lvalue/rvalue) of the original argument expression by conditionally casting the named parameter to the value category encoded in T, hence “Perfect Forwarding” (same type, same cv-qualification, same value category).

#include <print> 
#include <string>
#include <utility>

template <typename T>
void say_hello(T&& name_param) {
   std::println("Hello, {}", std::forward<T>(name_param)); 
}

int main() { 
    say_hello(std::string{"World!"}); 
    
    std::string name = "Matt!";
    say_hello(name); 
  
    return 0; 
}

In this example, I use a DigitalInput that will be used by a Button class (a study case of Embedded Systems). Here I assume the DigitalInput is some sort of given class from an library that we cannot modify, hence we would like to replace it with a Mock to enable non-HIL (Hardware in The Loop) tests. So I created a Concept DigitalInputLike that gets satisfied IFF any type has the init() and read() function in them. I also made an example of a BAD DigitalInput Mock that does not have the required functions, it will spit out a compilation error (nice catch concepts!)

During coding, the difference between using Type Traits compared to using Concepts is we do not need to have an addition of typename std::enable_if_t in the template typename call of the Button class. We also replace the use of typename with DigitalInputLike, and that automatically functions as a constraint.

#include <concepts>
#include <print>

// DigitalInputLike Concept
template <typename T>
concept DigitalInputLike = requires(T t) {
	{ t.init() } -> std::same_as<void>;
	{ t.read() } -> std::convertible_to<int>;
};

// Button Class Template (Uses Concept to Constrain it's instantiation)
template<DigitalInputLike T>
class Button {
public:
	Button (T* input): m_DigitalInput(input) {}
	void init() {
		m_DigitalInput->init();
		// rest of logic...
	}
	int read() {
		return m_DigitalInput->read();
	}
private:
	T *m_DigitalInput;
};

// Digital Input (Real)
class DigitalInput { 
public:
	void init();
	int read();
	int process();
};

// Digital Input (Good Mock)
class DigitalInputMock { 
public:
	void init();
	int read();
};

// Digital Input (Bad Mock)
class DigitalInputMock_Bad { 
public:
	/* void init();  */ // init() missing!
	int not_read(); 	// read() missing!
};

auto main() -> int {
	std::println("Real Digital Input, will proceed successfully");
	DigitalInput digitalInput;
    Button<DigitalInput> buttonWithReal(&digitalInput); // succeed

	std::println("Good Mock, will proceed successfully");
	DigitalInputMock digitalInputMock;
    Button<DigitalInputMock> buttonWithMock(&digitalInputMock); // succeed
	
	std::println("Bad Mock, will fail to compile if run");
	DigitalInputMock_Bad digitalInputBad;
    Button<DigitalInputMock_Bad> buttonWithBadMock(&digitalInputBad); // SFINAE in action! Compile error

	return 0;
}

Output

(x86-64 clang 21.1.0 -std=c++23):

<source>:60:5: error: constraints not satisfied for class template 'Button' [with T = DigitalInputMock_Bad]
   60 |     Button<DigitalInputMock_Bad> buttonWithBadMock(&digitalInputBad); // SFINAE in action! Compile error
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:12:10: note: because 'DigitalInputMock_Bad' does not satisfy 'DigitalInputLike'
   12 | template<DigitalInputLike T>
      |          ^
<source>:7:6: note: because 't.init()' would be invalid: no member named 'init' in 'DigitalInputMock_Bad'
    7 |         { t.init() } -> std::same_as<void>;
      |             ^
1 error generated.
Compiler returned: 1

If the buttonWithBadMock is commented out, it will churn out this

Real Digital Input, will proceed successfully
Good Mock, will proceed successfully
Bad Mock, will fail to compile if run

This is a cool list made by Erarnitox

Github Project: github.com/royyandzakiy/cpp-modules-example

There are no more header explosion, seperation of includes and src folders, the dreadful circular header includes, or the need to declare functions; which I find very compelling.

Modules still very much allows to use the traditional #include <header>, as long as it gets placed correctly.

I plan to slowly refactor one of my Native Windows Dekstop app to adopt Modules

Here is a good video from CppCon 2023 to learn the basics of it:

C++ Modules: Getting Started Today - Andreas Weis - CppCon 2023

Note: per today, I have tried the latest gcc and clang compilers (in windows) and they do not yet support Modules out of the box (need to either prepare the std module, or add compilation options). cmiiw

A different approach I find interesting is rather than ‘inheriting’ member variables, it can be done by injecting those variables during initialization (composition). Templates then help me create mocks of some annoying Windows Runtime specific objects like BluetoothAdvertisementWatcher.

Here is some snippets of using Type Traits to enable SFINAE (Substitution Failure is Not an Error), making this kind of Mocking possible.

In this example, I made a digital_input that will be inserted inside a Button class (a study case of Embedded Systems). Here I assume the digital_input is some sort of given library that I need to replace with a Mock. So I created a type trait that gets satisfied iff any type has the init() and read() function in them. I also made an example of a BAD digital_input_mock that does not have the required functions, hence spitting out a compilation error (noice!)

// ----------- Type Traits ----------- 
// This is the default fallback of the return Type Trait if after any other template 
// specialization fails
template<typename T, typename = void>
struct is_digital_input_like : std::false_type {};

// Here, declval acts as a silent instance of T, decltype ensures init() and read() exists, 
// resulting into an std::true_type as the final return of template type trait
template<typename T>
struct is_digital_input_like<T, std::void_t<
    decltype(std::declval<T>().init()),
    decltype(std::declval<T>().read())>> : std::true_type {};

// This is a helper to extract the value of the then either std::true_type or false_type
// into the primitive boolean value of `true` or `false`
template<typename T>
constexpr bool is_digital_input_like_v = 
	is_digital_input_like<T>::value;

// ----------- Button Template Class ----------- 
template <typename T, typename = std::enable_if_t<is_digital_input_like_v<T>>>
class Button {
public:
	MyButton(T *input) : m_DigitalInput(input) {}

	void init() {
		m_DigitalInput->init();
		// rest of logic...
	}

	int read() {
		return m_DigitalInput->read();
	}

private:	
	T *m_DigitalInput;
};

// ----------- Digital Input Classes ----------- 
// Digital Input (Real)
class DigitalInput {
public:
	void init() {}
	bool read() { return value_; }

	void set_value(bool v) { value_ = v; }
private:
	bool value_{};
};

// Digital Input (Mock)
class DigitalInputMock {
public:
	void init();
	bool read();
};

auto main() -> int {
    DigitalInputMock digitalInput;
    Button<DigitalInputMock> buttonWithMock(&digitalInput);

	digitalInput.set_value(true);
	std::println("Test Good Mock");
	std::println("button value: {}", button.read() ? "True" : "False");
	assert(button.read() == true);

	return 0;
}

Output:

Test Good Mock
button value: True
# assert passess succesfully

// ...

// Digital Input (Bad Mock)
class DigitalInputMock_Bad { 
public:
	/* void init();  */ // init() missing!
	bool not_read(); 	// read() missing!
};

auto main() -> int {
    DigitalInputMock_Bad digitalInputBad;
	std::println("Testing Bad Mock");
    Button<DigitalInputMock_Bad> buttonWithBadMock(&digitalInputBad); 
	// SFINAE in action! Resulting in a Compile error caused by the Type Trait returning std::false_type

	return 0;
}

Output:

main.cpp(281,5): error C2976: 'Button': too few template arguments, see declaration of 'Button'

Here, Cherno shares his take on it. He uses Premake (not CMake), and seperates a general Core and App architecture, to later be extendable to more Core components.

The Cherno - How to Properly Setup C++ Projects

Here’s another take, the Open Age of Empire (one of my favorite games as a kid), it also has some great docs.

github.com/SFTtech/openage

I’m keen to learning more professional and scalable C++ project setups.

github.com/royyandzakiy/cmake-spdlog-logger

Clean CMake for C++ (library) developers - Kerstin Keller - Meeting C++ 2024