This site serves as a place for me to share some of my learnings and ideas on software development. Most of the blog focuses on my interests in C++, unit testing, software architecture/design, and medical device development.
I am hopeful that this blog gives an opportunity for engagement with others, so please reach out if you have any feedback!
Subscribe to updates via RSS Feed
At C++ now 2024, I had the pleasure of giving my first lightning talk. Although I presented this as a debugging technique for software, this really could be applied to solving any problem where you're having trouble coming up with a solution.
Let me hear your thoughts in the comments below!
Learn how to set up Google Test (Gtest) with CMake in Compiler Explorer (Godbolt) for efficient C++ unit testing in a multi-file project environment. This approach streamlines the development process, especially for personal projects or when you need a quick, sharable testing setup.
Compiler Explorer (CE), also known as godbolt.org, has been a game-changer for many software engineers, myself included. Over the past four years, it has significantly impacted my development process. This tool's influence extends beyond individual developers; even tech giants like Google incorporate CE into their official processes. The C++ community (and many others) owes a debt of gratitude to Matt Godbolt for creating this invaluable resource.
One of CE's most powerful applications is in learning how to perform Test Driven Development (TDD). Previously, setting up a TDD environment could take hours. With CE and some guidance from Niall Cooling's blog, I was able to start unit testing in under two minutes. This accessibility extends to various devices, from desktops to tablets, and even smartphones (though mobile usage has its limitations).
While CE's Gtest integration works seamlessly for single-file projects, things get more complex when you need to separate source code and unit tests. This blog post will guide you through setting up Gtest with CMake in Compiler Explorer for multi-file projects, sharing insights from my experience and offering solutions to common challenges.
Decision-Making Isolation is a design philosophy that emphasizes separating the decision-making in code from the IO (gathering inputs to the decisions and making outputs based on those decisions) and the wiring code (which connects the decision-making and IO). DMI emphasizes invariance as a key concept in choosing how to structure code and prioritizes free functions over classes. The goal is to achieve a high level of purity that makes code easy to read, modify, extend, and test.
DMI was presented at C++Now 2024! The recording of that presentation is expected to be posted to YouTube in the summer of 2024.
This blog is a work in progress, so please check back soon! In the meantime, check out my invariance blog in which I explore this key concept.
The term 'invariant' is one of the linchpins of Decision Making Isolation. It is used in the Cpp Core Guidelines as the reason to use a class versus struct. But what does it really mean?
Before we discuss invariance, let's take a look at what else the Cpp Core Guidelines say about the difference between a class and struct.
class rather than struct if any member is non-public
Reason: Readability. To make it clear that something is being hidden/abstracted. This is a useful convention.While class and struct are relatively equivalent in C++, the Guidelines set the convention that structs are intended to only contain public members. Because all public data members can be directly modified, I believe it can be inferred that structs also shouldn't have public member functions. In the forthcoming Decision Making Isolation (DMI) blog, we'll go more into the preference for free functions. For now, we'll assume that structs only have public data members and no functions.