6 ms·

Practical Guide to Bare Metal C++

137 points by ibobev 8mo ago

pjmlp 8mo ago
While tag dispatching used to be a widely used idiom in C++ development, it was a workaround for which nowadays there are much better alternatives with constexpr, and concepts.
- tialaramex 8mo ago
  Surely one of the obvious reasons you'd want tagged dispatch in C++ isn't obviated by either of those features? Or am I missing something? Suppose Doodads can be constructed from a Foozle either with the Foozle Resigned or with the Foozle Submitted. Using tagged dispatch we make Resigned and Submitted types and the Doodad has two specialised constructors for the two types even though substantively we pass only the Foozle in both cases. In a language like Rust all the constructors have names, it's obvious what Vec::with_capacity does while you will still see C++ programmers who thought constructing a std::vector with a single integer parameter does the same because it's just a constructor and you'd need to memorize what happens.
  - quuxplusone 8mo ago
    I wouldn't call the idiom you describe (like with unique_lock's defer_lock_t constructor) "tag dispatch"; to me, one defining characteristic of the "tag dispatch idiom" is that the tag you're dispatching on is computed somehow (e.g. by evaluating iterator_traits<T>::iterator_category()). The idiom you're describing, I'd call simply "a constructor overload set" that happens to use the names of "disambiguation tags" to distinguish semantically different constructors because — as you point out — C++ doesn't permit us to give distinct names to the constructor functions themselves. For more on disambiguation tags, see https://quuxplusone.github.io/blog/2025/12/03/tag-types/ https://quuxplusone.github.io/blog/2025/12/03/tag-types/ and https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3940r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p39...
  - pjmlp 8mo ago
    You use if constexpr with requires expressions, to do poor man's reflection on where to dispatch, and eventually with C++26, you do it with proper reflection support.
VorpalWay 8mo ago
Why does the link go to the abstract classes heading, halfway down the page?
menaerus 8mo ago
Outdated, opinionated, platform-specific, and incorrect.
- superxpro12 8mo ago
  Bare metal firmware tends to be platform specific tho.
  - menaerus 8mo ago
    rPi with GCC 4.7 is neither firmware nor bare metal. GCC 4.7 is almost 15 years old.
    - bigstrat2003 8mo ago
      Not firmware sure, but if one boots the Pi from the software that's just as bare metal as anything else. And the age of the GCC version is completely irrelevant to whether something is bare metal.
      - menaerus 8mo ago
        Pi runs Linux. That's software. Not bare metal. Bare metal is when you're running without OS, or at light abstraction such as RTOS. Bare metal is normally associated with chips without MMU. Pi runs SoC. I didn't say that GCC version is relevant to bare metal definition, I said it's 15 years old. And when you try to draw conclusions, and derive strong opinion, based on the codegen output but you're using 15 year old toolchain, and btw pretty shitty CPU core, something isn't quite right. This article is just a good display of never ending cargo-cult programming myths.
        andrewf 8mo ago
        https://github.com/arobenko/embxx_on_rpi/blob/master/src/asm/startup.s https://github.com/arobenko/embxx_on_rpi/blob/master/src/asm... Their stuff isn't running on top of Linux on the Pi.
saltmate 8mo ago
This seems very well written, but has a lot of requirements/previous knowledge required by a reader. Are there similar resources that fill these gaps?
- birdsongs 8mo ago
  I only skimmed the book, but I think this is an artifact of the embedded engineering side. (Something I do professionally.) I've seen a lot of new people come into my team as juniors, or regular C/C++ engineers that convert to embedded systems. There is a real lack of good, concise resources for them, and the best result I've had is just mentoring them and teaching as we go. You could look for an intro to embedded systems resource. Or just get a dev kit for something. Go different than the standard Pi or Arduino. Try and get something like a STM32G0 dev kit working and blinking its lights. It's less polished, but you'll have to touch more things and learn more. If you want, core areas I would suggest to research are the very low level operations of a processor: * How does the stack pointer work? (What happens to this during function calls? * How do parameters get passed to functions by value, by reference? What happens when you pass a C++ class to a function by value? What is a deep vs shallow copy of a C++ object, and how does that work when you don't have an OS or MMU? * Where is heap memory stored? Why do we have a heap and a stack? How do these work in the absence of an OS? * The Program Counter? (PC register). What happens to this as program execution progresses? * What happens when a processor boots, how does it start receiving instructions? (This is vague, you could read the datasheet for something like the STM32G0 microcontroller, or the general Arm Cortex M0 core.) * How are data/instructions loaded from disk to memory to cache to register? What are these divisions and why do we have them? * Basic assembly language, you should know how loads and stores work, basic arithmetic, checks/tests/comparisons, jump operations. * How do interrupts work, what's an ISR, IRQ, IVT? How do peripherals like UART, I2C (also what are these?), handle incoming data when you have a main execution thread already running on a single core processor? Some of this may be stuff you already know, or seem rudimentary and not exactly relevant, but they are things that have to be rock solid before you start thinking about how compilers for differently languages, like C++, create machine code that runs on a processor without an OS. Assembly is often overlooked, but a critical skill here. It's really not that bad. Often when working with C++ (or Rust) on embedded systems, if I'm unsure of something, my first step is to decompile and dump the assembly to investigate, or step through the assembly with GDB via a JTAG probe on the target processor if the target was too small to hold all the debug symbols (very common). Anyways, this may have been more than you were asking for. Just me typing out thoughts over my afternoon coffee.
myrmidon 8mo ago
> There are multiple articles of how C++ is superior to C, that everything you can do in C you can do in C++ with a lot of extras, and that it should be used even with bare metal development An interesting perspective. Could turn it around as "everything you can do in C++ you can do in C with a lot less language complexity". My personal experience with low-level embedded code is that C++ is rarely all that helpful, tends to bait you into abstractions that don't really help, brings additional linker/compiler/toolchain complexity and often needs significant extra work because you can't really leverage it without building C++ abstractions over provided C-apis/register definitions. Would not generally recommend.
- g947o 8mo ago
  Mind if I ask whether you speak of that from a professional embedded system engineer's perspective?
  - myrmidon 8mo ago
    I do. But talking about low-level embedded stuff here. Generally, the more you deviate from your vendors "happy path", the more busy work/unexpected difficulties you will run into, and a solid grasp of how exactly architecture and toolchain work might become necessary (while staying on the "happy path" allows you to stay blissfully unaware).
    - technothrasher 8mo ago
      I struggle with this deviating from the vendor's "happy path" often. I mostly use the STM32 chips, and I don't particularly care for their HAL library. I find it over complicated and often has bugs in it that I have to track down and fix. But boy is it nice to use their STM32CubeMX program to generate all the low level code so I can just get to work. I tend to end up building my own low level libraries during my free time because I enjoy it and it gives me a better idea of how the hardware is actually working, but using the STM32 HAL library to write my actual client code at work.
      - 8mo ago
m00dy 8mo ago
just use Rust, and never look back.
- soci 8mo ago
  Why is this comment downvoted? I mean, is it downvoted because Rust is bad for embeded systems?
  - bigstrat2003 8mo ago
    Probably because it's kind of annoying to bring up Rust in a C++ thread.
NooneAtAll3 8mo ago
link has extra "#_abstract_classes" in it that it would be better without
randusername 8mo ago
> Although there is an opinion that templates are dangerous because of executable code bloating, I think that templates are developer’s friends, but the one must know the dangers and know how to use templates effectively. But again, it requires time and effort to get to know how to do it right. idk man, obviously I don't know much since I don't have my own online book, but templates would not be at the start of my list when selling C++ for bare-metal. unit suffixes, namespaces, RAII, constexpr, OOP (interfaces mostly), and I like a lot of the STL in avoiding inscrutable "raw loops". I like the idea of templates, but it feels like a different and specialized skillset. If you are considering C++ from C, why not ease into it?
- bluGill 8mo ago
  Most of the good parts of the STL are implemented as templates. If you are considering C++ from C, then treating it like C with the STL templates is a great first step. Over time you will discover other useful features of C++ that solve specific problems. Virtual functions in a class - better than writing a table of function pointers. Lambda - sometimes much better than a function pointer. Custom templates - better than doing the same thing in macros (at least some times). Exceptions are sometimes really nice for error handling (and contrary to popular belief are not slow) And so on - C++ has a lot of features that can be useful, but most of them are features that can also be abused in places they don't belong creating a real problem.
- lkjdsklf 8mo ago
  Templates don’t have to be complicated. Just very basic type substitution is one of the most useful uses of templates and is useful in pretty much all software They’re also useful when you can’t use virtual dispatch. Concepts help a lot in making that tolerable. Sure they can get stupid complicated and ugly as hell, but you don’t have to do that. Even their basic form is very useful That said, RAII is probably the must useful thing
mdocc 8mo ago
>StaticQueue: LinearisedIterator Using C++ iterator interface to fix the main problem of a standard ring buffer of non-contiguous regions is a cute idea, but I like to use a "bip buffer"[1] instead which actually always gives you real contiguous regions so you can pass the pointers to things like a dma engine. [1] https://ferrous-systems.com/blog/lock-free-ring-buffer/ https://ferrous-systems.com/blog/lock-free-ring-buffer/ The tradeoff is that you have in the worse case only half the buffer available - the ring buffer essentially becomes a kind of double buffer where you periodically switch between writing/reading at the end or the beginning of the storage.
embeng4096 8mo ago
I took a brief skim through so apologies if I missed that it was mentioned, but wanted to bring up the Embedded Template Library[0]. The (over)simplified concept is: it provides a statically-allocated subset (but large subset) of the C++ standard library for use in embedded systems. I used it recently in a C++ embedded project for statically-allocated container/list types, and for parsing strings, and the experience was nice. [0]: https://www.etlcpp.com/ https://www.etlcpp.com/
- maldev 8mo ago
  So I use C++ heavily in the kernel. But couldn't you just set your own allocator and a couple other things and achieve the same effect and use the actual C++ STL? In kernel land, at the risk of simplifying, you just implement allocators and deallocators and it "just works", even on c++ 26.
  - nly 8mo ago
    Do you typically just compile with -fno-rtti -fno-exceptions -nostdlib ? Last time I did embedded work this was basically all that was required.
    - nulltrace 8mo ago
      Those three flags cover most of it. One gotcha: -fno-exceptions makes `new` return nullptr instead of throwing, so if any library code expects exceptions you get silent corruption. We added -fcheck-new to catch that. Also -nostdlib means no global constructors run, so static objects with nontrivial ctors need you to call __libc_init_array yourself.
daemin 8mo ago
I just thought I'd mention that Khalil Estell is doing some work regarding exceptions in embedded and bare metal programming. In the first of his talks about this topic (https://www.youtube.com/watch?v=bY2FlayomlE https://www.youtube.com/watch?v=bY2FlayomlE) he mentions that a lot of the bloat in exception handling is including printf in order to print out the message when terminating the program. For those interested he has another presentation on this topic https://www.youtube.com/watch?v=wNPfs8aQ4oo https://www.youtube.com/watch?v=wNPfs8aQ4oo
- chris_money202 8mo ago
  Didn’t watch the video but as opposed to what? Printf is definitely the most efficient way to retrieve the info needed to begin initial triage especially in “hacking” or bring up where a formal process isn’t defined
  - daemin 8mo ago
    There are processors and platforms where including the standard library feature to print text to standard output significantly increases the size of the binary. In such cases just enabling exceptions also enables this feature only for the purpose of outputting a termination message, which does not get displayed or read because the device doesn't have a way to emit standard output.
Panzerschrek 8mo ago
> Yes, indeed, there are two calls to two different functions. However, the assembler code of these functions is almost identical. As I understand this is due to requirement for distinct C++ functions to have unique addresses.
theICEBeardk 8mo ago
While this is helpful in a way this blog also contains outdated information. Given that in embedded you most of the time build the world and have most of your stuff as source code you should never get stuck on an old compiler unless it is a one-shot project. And that leads to the ability to use modern C++ methods in places where it is highly useful such as the ability to use "if constexpr" and templates to make your somewhat generic code optimal for a specific usage scenario like writing a templated driver that adapts to the specific hardware variant you are building. This means you can often run without making runtime decisions on hardware situations that cannot ever occur because the specific chip or board does not even have the option. Also I noticed the virtual interface mentioned and I would express a minor point of caution there for embedded developers. A virtual interface is really meant for dynamic/runtime situations where the object behind the interface can change at runtime. In embedded that is a more rare case. Consider using concepts to define such interfaces and pass the concrete objects as template parameters where it makes sense. I have on several occasions these last four years reduced the binary size overhead of products by doing this as an object accessed through a virtual interface prevents the removal of unused methods from the final binary (they have to be present even with devirtualization happening to reduce the indirection cost). Also template bloat is real but also a somewhat over-"hyped" problem in embedded. It occurs when the same template is run several times to produce many variations of the same template. In most template programs this will not happen by accident. Mainly avoid making any reoccuring template configuration apart of the type. Instead we now have the option of initializing objects during compile time using constexpr objects. Make your configuration of the object that way (maybe even consteval) and use that in "if constexpr" if possible. All compilers relevant in embedded can manage to put this configuration into the read-only/flash memory and load it in during start-up/boot.

137 points by ibobev 8mo ago

pjmlp 8mo ago

While tag dispatching used to be a widely used idiom in C++ development, it was a workaround for which nowadays there are much better alternatives with constexpr, and concepts.

tialaramex 8mo ago
Surely one of the obvious reasons you'd want tagged dispatch in C++ isn't obviated by either of those features? Or am I missing something? Suppose Doodads can be constructed from a Foozle either with the Foozle Resigned or with the Foozle Submitted. Using tagged dispatch we make Resigned and Submitted types and the Doodad has two specialised constructors for the two types even though substantively we pass only the Foozle in both cases. In a language like Rust all the constructors have names, it's obvious what Vec::with_capacity does while you will still see C++ programmers who thought constructing a std::vector with a single integer parameter does the same because it's just a constructor and you'd need to memorize what happens.
- quuxplusone 8mo ago
  I wouldn't call the idiom you describe (like with unique_lock's defer_lock_t constructor) "tag dispatch"; to me, one defining characteristic of the "tag dispatch idiom" is that the tag you're dispatching on is computed somehow (e.g. by evaluating iterator_traits<T>::iterator_category()). The idiom you're describing, I'd call simply "a constructor overload set" that happens to use the names of "disambiguation tags" to distinguish semantically different constructors because — as you point out — C++ doesn't permit us to give distinct names to the constructor functions themselves. For more on disambiguation tags, see https://quuxplusone.github.io/blog/2025/12/03/tag-types/ https://quuxplusone.github.io/blog/2025/12/03/tag-types/ and https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3940r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p39...
- pjmlp 8mo ago
  You use if constexpr with requires expressions, to do poor man's reflection on where to dispatch, and eventually with C++26, you do it with proper reflection support.

VorpalWay 8mo ago

Why does the link go to the abstract classes heading, halfway down the page?

menaerus 8mo ago

Outdated, opinionated, platform-specific, and incorrect.

superxpro12 8mo ago
Bare metal firmware tends to be platform specific tho.
- menaerus 8mo ago
  rPi with GCC 4.7 is neither firmware nor bare metal. GCC 4.7 is almost 15 years old.
  - bigstrat2003 8mo ago
    Not firmware sure, but if one boots the Pi from the software that's just as bare metal as anything else. And the age of the GCC version is completely irrelevant to whether something is bare metal.
    - menaerus 8mo ago
      Pi runs Linux. That's software. Not bare metal. Bare metal is when you're running without OS, or at light abstraction such as RTOS. Bare metal is normally associated with chips without MMU. Pi runs SoC. I didn't say that GCC version is relevant to bare metal definition, I said it's 15 years old. And when you try to draw conclusions, and derive strong opinion, based on the codegen output but you're using 15 year old toolchain, and btw pretty shitty CPU core, something isn't quite right. This article is just a good display of never ending cargo-cult programming myths.
      - andrewf 8mo ago
        https://github.com/arobenko/embxx_on_rpi/blob/master/src/asm/startup.s https://github.com/arobenko/embxx_on_rpi/blob/master/src/asm... Their stuff isn't running on top of Linux on the Pi.

saltmate 8mo ago

This seems very well written, but has a lot of requirements/previous knowledge required by a reader. Are there similar resources that fill these gaps?

birdsongs 8mo ago
I only skimmed the book, but I think this is an artifact of the embedded engineering side. (Something I do professionally.) I've seen a lot of new people come into my team as juniors, or regular C/C++ engineers that convert to embedded systems. There is a real lack of good, concise resources for them, and the best result I've had is just mentoring them and teaching as we go. You could look for an intro to embedded systems resource. Or just get a dev kit for something. Go different than the standard Pi or Arduino. Try and get something like a STM32G0 dev kit working and blinking its lights. It's less polished, but you'll have to touch more things and learn more. If you want, core areas I would suggest to research are the very low level operations of a processor: * How does the stack pointer work? (What happens to this during function calls? * How do parameters get passed to functions by value, by reference? What happens when you pass a C++ class to a function by value? What is a deep vs shallow copy of a C++ object, and how does that work when you don't have an OS or MMU? * Where is heap memory stored? Why do we have a heap and a stack? How do these work in the absence of an OS? * The Program Counter? (PC register). What happens to this as program execution progresses? * What happens when a processor boots, how does it start receiving instructions? (This is vague, you could read the datasheet for something like the STM32G0 microcontroller, or the general Arm Cortex M0 core.) * How are data/instructions loaded from disk to memory to cache to register? What are these divisions and why do we have them? * Basic assembly language, you should know how loads and stores work, basic arithmetic, checks/tests/comparisons, jump operations. * How do interrupts work, what's an ISR, IRQ, IVT? How do peripherals like UART, I2C (also what are these?), handle incoming data when you have a main execution thread already running on a single core processor? Some of this may be stuff you already know, or seem rudimentary and not exactly relevant, but they are things that have to be rock solid before you start thinking about how compilers for differently languages, like C++, create machine code that runs on a processor without an OS. Assembly is often overlooked, but a critical skill here. It's really not that bad. Often when working with C++ (or Rust) on embedded systems, if I'm unsure of something, my first step is to decompile and dump the assembly to investigate, or step through the assembly with GDB via a JTAG probe on the target processor if the target was too small to hold all the debug symbols (very common). Anyways, this may have been more than you were asking for. Just me typing out thoughts over my afternoon coffee.

myrmidon 8mo ago

> There are multiple articles of how C++ is superior to C, that everything you can do in C you can do in C++ with a lot of extras, and that it should be used even with bare metal development An interesting perspective. Could turn it around as "everything you can do in C++ you can do in C with a lot less language complexity". My personal experience with low-level embedded code is that C++ is rarely all that helpful, tends to bait you into abstractions that don't really help, brings additional linker/compiler/toolchain complexity and often needs significant extra work because you can't really leverage it without building C++ abstractions over provided C-apis/register definitions. Would not generally recommend.

g947o 8mo ago
Mind if I ask whether you speak of that from a professional embedded system engineer's perspective?
- myrmidon 8mo ago
  I do. But talking about low-level embedded stuff here. Generally, the more you deviate from your vendors "happy path", the more busy work/unexpected difficulties you will run into, and a solid grasp of how exactly architecture and toolchain work might become necessary (while staying on the "happy path" allows you to stay blissfully unaware).
  - technothrasher 8mo ago
    I struggle with this deviating from the vendor's "happy path" often. I mostly use the STM32 chips, and I don't particularly care for their HAL library. I find it over complicated and often has bugs in it that I have to track down and fix. But boy is it nice to use their STM32CubeMX program to generate all the low level code so I can just get to work. I tend to end up building my own low level libraries during my free time because I enjoy it and it gives me a better idea of how the hardware is actually working, but using the STM32 HAL library to write my actual client code at work.
    - 8mo ago

m00dy 8mo ago

just use Rust, and never look back.

soci 8mo ago
Why is this comment downvoted? I mean, is it downvoted because Rust is bad for embeded systems?
- bigstrat2003 8mo ago
  Probably because it's kind of annoying to bring up Rust in a C++ thread.

NooneAtAll3 8mo ago

link has extra "#_abstract_classes" in it that it would be better without

randusername 8mo ago

> Although there is an opinion that templates are dangerous because of executable code bloating, I think that templates are developer’s friends, but the one must know the dangers and know how to use templates effectively. But again, it requires time and effort to get to know how to do it right. idk man, obviously I don't know much since I don't have my own online book, but templates would not be at the start of my list when selling C++ for bare-metal. unit suffixes, namespaces, RAII, constexpr, OOP (interfaces mostly), and I like a lot of the STL in avoiding inscrutable "raw loops". I like the idea of templates, but it feels like a different and specialized skillset. If you are considering C++ from C, why not ease into it?

bluGill 8mo ago
Most of the good parts of the STL are implemented as templates. If you are considering C++ from C, then treating it like C with the STL templates is a great first step. Over time you will discover other useful features of C++ that solve specific problems. Virtual functions in a class - better than writing a table of function pointers. Lambda - sometimes much better than a function pointer. Custom templates - better than doing the same thing in macros (at least some times). Exceptions are sometimes really nice for error handling (and contrary to popular belief are not slow) And so on - C++ has a lot of features that can be useful, but most of them are features that can also be abused in places they don't belong creating a real problem.
lkjdsklf 8mo ago
Templates don’t have to be complicated. Just very basic type substitution is one of the most useful uses of templates and is useful in pretty much all software They’re also useful when you can’t use virtual dispatch. Concepts help a lot in making that tolerable. Sure they can get stupid complicated and ugly as hell, but you don’t have to do that. Even their basic form is very useful That said, RAII is probably the must useful thing

mdocc 8mo ago

>StaticQueue: LinearisedIterator Using C++ iterator interface to fix the main problem of a standard ring buffer of non-contiguous regions is a cute idea, but I like to use a "bip buffer"[1] instead which actually always gives you real contiguous regions so you can pass the pointers to things like a dma engine. [1] https://ferrous-systems.com/blog/lock-free-ring-buffer/ https://ferrous-systems.com/blog/lock-free-ring-buffer/ The tradeoff is that you have in the worse case only half the buffer available - the ring buffer essentially becomes a kind of double buffer where you periodically switch between writing/reading at the end or the beginning of the storage.

embeng4096 8mo ago

I took a brief skim through so apologies if I missed that it was mentioned, but wanted to bring up the Embedded Template Library[0]. The (over)simplified concept is: it provides a statically-allocated subset (but large subset) of the C++ standard library for use in embedded systems. I used it recently in a C++ embedded project for statically-allocated container/list types, and for parsing strings, and the experience was nice. [0]: https://www.etlcpp.com/ https://www.etlcpp.com/

maldev 8mo ago
So I use C++ heavily in the kernel. But couldn't you just set your own allocator and a couple other things and achieve the same effect and use the actual C++ STL? In kernel land, at the risk of simplifying, you just implement allocators and deallocators and it "just works", even on c++ 26.
- nly 8mo ago
  Do you typically just compile with -fno-rtti -fno-exceptions -nostdlib ? Last time I did embedded work this was basically all that was required.
  - nulltrace 8mo ago
    Those three flags cover most of it. One gotcha: -fno-exceptions makes `new` return nullptr instead of throwing, so if any library code expects exceptions you get silent corruption. We added -fcheck-new to catch that. Also -nostdlib means no global constructors run, so static objects with nontrivial ctors need you to call __libc_init_array yourself.

daemin 8mo ago

I just thought I'd mention that Khalil Estell is doing some work regarding exceptions in embedded and bare metal programming. In the first of his talks about this topic (https://www.youtube.com/watch?v=bY2FlayomlE https://www.youtube.com/watch?v=bY2FlayomlE) he mentions that a lot of the bloat in exception handling is including printf in order to print out the message when terminating the program. For those interested he has another presentation on this topic https://www.youtube.com/watch?v=wNPfs8aQ4oo https://www.youtube.com/watch?v=wNPfs8aQ4oo

chris_money202 8mo ago
Didn’t watch the video but as opposed to what? Printf is definitely the most efficient way to retrieve the info needed to begin initial triage especially in “hacking” or bring up where a formal process isn’t defined
- daemin 8mo ago
  There are processors and platforms where including the standard library feature to print text to standard output significantly increases the size of the binary. In such cases just enabling exceptions also enables this feature only for the purpose of outputting a termination message, which does not get displayed or read because the device doesn't have a way to emit standard output.

Panzerschrek 8mo ago

> Yes, indeed, there are two calls to two different functions. However, the assembler code of these functions is almost identical. As I understand this is due to requirement for distinct C++ functions to have unique addresses.

theICEBeardk 8mo ago

While this is helpful in a way this blog also contains outdated information. Given that in embedded you most of the time build the world and have most of your stuff as source code you should never get stuck on an old compiler unless it is a one-shot project. And that leads to the ability to use modern C++ methods in places where it is highly useful such as the ability to use "if constexpr" and templates to make your somewhat generic code optimal for a specific usage scenario like writing a templated driver that adapts to the specific hardware variant you are building. This means you can often run without making runtime decisions on hardware situations that cannot ever occur because the specific chip or board does not even have the option. Also I noticed the virtual interface mentioned and I would express a minor point of caution there for embedded developers. A virtual interface is really meant for dynamic/runtime situations where the object behind the interface can change at runtime. In embedded that is a more rare case. Consider using concepts to define such interfaces and pass the concrete objects as template parameters where it makes sense. I have on several occasions these last four years reduced the binary size overhead of products by doing this as an object accessed through a virtual interface prevents the removal of unused methods from the final binary (they have to be present even with devirtualization happening to reduce the indirection cost). Also template bloat is real but also a somewhat over-"hyped" problem in embedded. It occurs when the same template is run several times to produce many variations of the same template. In most template programs this will not happen by accident. Mainly avoid making any reoccuring template configuration apart of the type. Instead we now have the option of initializing objects during compile time using constexpr objects. Make your configuration of the object that way (maybe even consteval) and use that in "if constexpr" if possible. All compilers relevant in embedded can manage to put this configuration into the read-only/flash memory and load it in during start-up/boot.