General cleanup for the C++26 article

Author: tomice

_posts/2026-04-05-exploring-c++26.md

@@ -14,21 +14,22 @@ on the fun and read the spec to see what new language features were added.
 
 This article is more or less a list of findings I think will be useful for
 those of us who work in slightly more constrained environments, rather than
-an overall look at everything in the spec. I will mostly be looking into
-features that help solve real problems within the embedded world and tend to
-be the most annoying to maintain - userspace daemons, device-facing middleware,
-debug utilities, platform layers, etc.
+an overall look at everything in the spec. I'll try to look into features that
+help solve real problems within the embedded world and tend to be annoying to
+maintain (userspace daemons, debug utilities, platform layers, etc.), but some
+examples might be slightly esoteric to help convey the intent of the feature.
 
 Before we begin, I should note the usual caveats. Those who are not used to
 reading ISO specs like the currently existing
 [C++26 draft spec](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/n5014.pdf)
 should probably start with the
 [cppreference page](https://en.cppreference.com/w/cpp/26.html).
-The cppreference page will get you right into the heart of what is being added,
-and if you need more information, you can cross-reference the ISO PDF for more
-detail. From there, make sure to always check the cppreference compiler support
-section to see what feature(s) are available to you. As of writing this, the
-[meta-clang](https://github.com/kraj/meta-clang/tree/scarthgap-clang20) repo
+The cppreference page will be very "to the point" in terms of of what is being
+added, and if you need more information, you can cross-reference the ISO PDF
+for more detail. From there, make sure to always check the cppreference
+compiler support section to see what feature(s) are available to you. As of
+writing this, the
+[meta-clang](https://github.com/kraj/meta-clang/tree/scarthgap-clang20) layer
 supports version 20,
 [openembedded-core](https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/gcc)
 supports GCC 15.2. Pretty much all references will be from these links, so make
@@ -40,13 +41,10 @@ A lot of embedded C++ ends up looking older than it needs to because teams
 optimize for predictability and portability. That is a totally reasonable
 approach, especially if you need massive support across multiple toolchains.
 The downside is that codebases with homegrown abstractions, such as custom
-fixed-capacity containers, custom debug traps, custom overflow helpers, and
-such tend to become less predictable as time goes on. C++26 standardizes
-several of those missing pieces for us. For example, `std::inplace_vector`
-provides a bounded, contiguous, resizable container with compile-time fixed
-capacity. `<stdckdint.h>` provides checked integer arithmetic. `<debugging>`
-adds debugger detection and breakpoints. `<rcu>` and `<hazard_pointer>`
-standardize two major safe-reclamation approaches.
+containers, traps, overflow helpers, and other custom platform code tend to
+become less predictable as time goes on. C++26 standardizes several things that
+might help make these a bit more robust in nature without relying on
+potential UB. Let's jump into it.
 
 ## `std::execution`
 
@@ -55,7 +53,7 @@ A service or daemon starts out very simple. It might start by reading a
 message, validating it, possibly transforming it, publishing it, and
 eventually updating some state. But then it grows threads, queues, timeouts,
 and more. Before long, the real logic is hidden under the sea of the
-synchronization hell, and becomes a bit of a massive pain to maintain.
+synchronization, and it becomes a bit of a massive pain to maintain.
 
 Enter `std::execution` - the execution control library in C++26
 that standardizes a model for async execution around schedulers, senders,
@@ -74,7 +72,7 @@ workflow as a series of stages, allowing us to focus on the work itself.
 
 Imagine a daemon that reads one frame from a device or socket, validates it,
 and then publishes it to the rest of the system. `std::execution` is perfect
-here as we can break each section up into individual stages, making it way
+here as we can break each section up into individual steps, making it way
 easier to test and reason about.
 
 ```cpp
@@ -143,18 +141,18 @@ time to [check it out](https://www.youtube.com/watch?v=7z9NNrRDHQU) as it is
 extremely fascinating...ambitious claims aside.
 
 The design in [P2996](https://isocpp.org/files/papers/P2996R13.html) centers on
-reflection values (`std::meta::info`), the reflection operator `^^` (love calling
-this guy the "cat's ears operator"), compile-time queries through `consteval`
-metafunctions, and splicing reflected entities back into code.
-
-The paper explicitly covers member enumeration and related introspection
-capabilities that make real compile-time structural queries possible which can
-be insanely powerful. However, for embedded Linux, the best way to think about
-reflection is probably not advanced metaprogramming, but rather a way to
-help delete duplicate metadata. A lot of platform code still defines the same
-thing twice - once as a C++ type, and again as a macro list, serializer table,
-or maybe something like a config schema. Reflection lets the type itself become
-the source of truth. Heck, even getting rid of legacy
+reflection values (`std::meta::info`), the reflection operator `^^` (love
+calling this guy the "cat's ears operator"), compile-time queries through
+`consteval`, and splicing reflected entities back into code.
+
+The paper explicitly covers extremely powerful and complex paradigms such as
+member enumeration and related introspection capabilities. These make real
+compile-time structural queries possible which can be insanely powerful.
+However, for embedded Linux, the best way to think about reflection is
+probably as a way to help delete duplicate metadata. A lot of platform code
+still defines the same thing twice - once as a C++ type, and again as a macro
+list, serializer table, or maybe something like a config schema. Reflection
+lets the type itself become the source of truth. Heck, even getting rid of legacy
 [X-macro use cases](https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros)
 would be a huge win alone.
 
@@ -226,29 +224,30 @@ verbose=true
 All without having to write code for every field. Normally, you would write
 some sort of `std::string` to dump the config, but you are duplicating the
 struct manually, and adding fields later on requires you to update not only the
-struct, but also any of those helper functions.
-
-Reflection is especially attractive anywhere you are doing that kind of work.
-Examples off the top of my head would be:
+struct, but also any of those helper functions. Reflection is especially
+attractive in those kinds of use cases. Examples off the top of my head would
+be:
 
 - Config dumps (as shown above)
 - Serializer/deserializer glue code
 - ABI or layout verification helpers
 
-Those are everywhere in our codebases, and we can drastically reduce places
-where type changes can silently drift from their associated glue code. This
-one does come with a bit of a cost, however. It is very easy to get into the
-weeds with insane template metaprogramming with how powerful these are, and
-you're right back to a readable mess that could have been solved with a simple
-X-macro. Use these with a bit of caution.
+Those tend to be everywhere in our codebases, and we can drastically reduce
+areas where type changes can silently drift from their associated glue code.
+
+This one does come with a bit of a cost, however. It is very easy to get into
+the weeds with insane template metaprogramming given how powerful these are.
+If you're not used to reading more modern C++ code, there is also an argument
+that the X-macro alternative is more straightforward. Those are totally valid
+arguments, so you need to weigh maintenance with some readability and possibly
+modern C++ language training tradeoffs.
 
 ## `<hazard_pointer>` and `<rcu>`
 
 Many platform daemons read things like:
 
 - Subscription lists
 - Cached device state
-- Registries
 - Config snapshots
 
 The hard part of making those structures concurrent is often not the swap
@@ -454,13 +453,16 @@ moves towards stronger correctness and safety expectations.
 
 ## `<stdckdint.h>`
 
-C++26 adds `<stdckdint.h>` which includes checked integer arithmetic functions
-like `ckd_add`, `ckd_sub`, and `ckd_mul`. These perform integer arithmetic and
-report whether the result can be represented in the destination type. These are
-perfect for areas where overflow bugs show up like computing buffer offsets,
-conversions between units, total packet size, etc. With these being part of the
-standard library now, you can reduce the amount of fallbacks or
-compiler-specific builtins trying to do the same thing.
+C++26 adds `<stdckdint.h>` that was originally found in the
+[C23 standard](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf)
+which includes checked integer arithmetic functions like `ckd_add`, `ckd_sub`,
+and `ckd_mul`. These perform integer arithmetic and report whether the result
+can be represented in the destination type. These are perfect for areas where
+overflow bugs show up like computing buffer offsets, conversions between units,
+total packet size, etc. With these being part of the library now, you can
+reduce the amount of fallbacks or compiler-specific builtins trying to do the
+same thing. And since they were part of the C23 codebase, you can use them in
+your C codebases, as well!
 
 ### Compute total size of a packet