Cpp

When working with embedded systems, naming might seem like a small detail, however it is not. Good naming conventions make code readable, maintainable, and portable. Poor naming, like Uart1 or Uart2, ties logic to hardware details, making future changes painful. Semantic names such as UartDebug or UartModem tell you what the peripheral in question does, not where it sits on the MCU. In this post, I’ll explore why semantic naming matters, provide a naming table for all layers, one of which I will be using in upcoming examples when writing more about embedded C++, and present sample scenarios that clarify the benefits. These recommendations are based on my experience and general best practices in embedded C++ development. ...

On my previous post about C++ Policies, a policy-based design was used for comparators and loggers, which are stateless function objects (they only call a single function). These types are empty, but as members they still occupy space because C++ guarantees distinct addresses for distinct subobjects. With C++20’s [[no_unique_address]] or Empty Base Optimization (EBO), programmers can make these truly zero-cost, which is huge for small, hot objects like iterators or adapters.1 ...

I’ve been reading about templates a lot lately and kept seeing the word policy. Which made me realized I wanted a single post that answers the question: What is a policy? Why do C++ sources keep mentioning them? How do compile-time policies (templates) compare to runtime strategies (virtuals/std::function)? And when should which be used? ...

Introduction C++20 shipped with Concepts — a long‑awaited way to express constraints on template parameters right where they live. Concepts turn the old “SFINAE and traits soup” into clear, readable predicates that the compiler can check for you. If you’ve ever stared at a 20‑line enable_if just to say “this needs to be integral,” this feature is for you. ...