Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Makes some really great points, similar to why C++ is not favored for embedded. C++ compilers are just too unpredictable and when trying to meet code limits in 128K, 32K or even 2K of flash, C++ is a nightmare. All of the major embedded SDKs (STM, Microchip, SiLabs, TI, NXP, I could go on) are written in C... and C only. MBED is C++, but I've never encountered or heard of an OEM or integrator using MBED in a real product.


Lots of folks use C++ on microcontrollers (including me!). I've definitely been working closer to the 32 bit processor, >= 128K flash world though.

Certain things are very nice about C++ as compared to C, especially C++11 on:

* type safety and expressiveness (aided by judicious use of templates)

* The constexpr keyword for real compile-time constants (again, type safety)

* RAII (often aided by statically allocated pools of memory from which one can then allocate objects from at runtime)

What kind of issues with code size have you had (and using which compiler)?


Which SDKs do you use that are C++?

I use Keil, IAR, Renesas's compiler, XM8/16/32 from Microchip, and GCC.

Which do you use?

One of the main features of C++, its object-oriented stuff, is built on top of constructors and destructors -- aka dynamic memory allocation. This sort of thing is not desirable on deeply embedded systems due to resource constraints and the very real spectre of heap fragmentation -- embedded stuff tends to rely on static memory allocation done at compile time or system startup.

C++ isn't quite as portable as C -- Not just the compilers which never quite supported the same combinations of features -- even if you just stuck with the ISO-ratified features -- but the language runtime, standard [template] library, and headers are far larger with various implementations including plenty of mis-features and quirks. All of this meant that it was quite common for C++ code to not even compile with a different toolchain -- especially when templates were used -- and even if it did compile, it might not actually function correctly.

If you restricted yourself to avoid the problematic areas of C++ (eg not using templates or dynamic allocations) you'll end up with a language that is basically C. So why not just use C? :)


GCC, and Keil.

As you said, there are no vendor SDKs out there (that I know of, anyways) that are C++. But it's not terribly hard to integrate them in to a C++ codebase / roll your own abstractions because you're dissatisfied with the ones the vendor gives you (;

Different compilers supporting different subsets of the standard is definitely an issue, and it can be a problem if you're trying to use the same code with several different toolchains.

GCC in particular however has been really good about keeping up with newer versions of the C++ standard. I like and use many of the things on this list (excepting the standard library features, which of course you usually can't use off the shelf because dynamic memory allocation): https://github.com/AnthonyCalandra/modern-cpp-features.

In particular, features such as constexpr lambda, if constexpr, and type traits are nice ways to do some compile-time computation while being type safe - they're a lot more pleasant to work with than C preprocessor macros.

And of course, templates. They're a nice way to express certain concepts and reduce duplication without making any impact on your code size. But only judiciously, otherwise you will wreck your compile times (;


Ah, you might also like this talk which goes into the gory details: https://youtu.be/c9Xt6Me3mJ4?t=2561


> Makes some really great points, similar to why C++ is not favored for embedded. C++ compilers are just too unpredictable and when trying to meet code limits in 128K, 32K or even 2K of flash, C++ is a nightmare. All of the major embedded SDKs (STM, Microchip, SiLabs, TI, NXP, I could go on) are written in C... and C only.

OTOH Arduino is C++ and works fine for millions of people, I've also dabbled a bit in various AVR, STM32 and ESP8266, all in C++.


Arduino is a sandbox for people with little experience in embedded programming to dip a toe. They aren't interested in writing optimized constrained code, which is what 99% of embedded programming for products is about. Two totally different spheres.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: