Actually C++ is not slower or more bloat than C, depending on the features

For example I do not use RTTI or exceptions, so that makes it about the
same as C for size. Yes you have to turn these features off in your
compiler (-fno-rtti, -fno-exceptions).  Sure you have trampolines or jump
tables for function overloading but you have to do the same in C. If you do
not use inheritance or function overloading you do not have the penalty.

I find that in most of my embedded projects the cost of development time is
more than the cost of the processor for 5 years of production, that is the
products are not super high volume products.  As such, reducing development
time is very important.   To this end I do things like write libraries and
test them, and then reuse them.  For example I write an abstract interface
class for a CharDevice, and BlockDevice.  Then a UART can be a CharDevice
and EEPROM a BlockDevice, SDCard is a BlockDevice, etc.  This allows faster
development.  Sure I can do this in C, but C++ basically does the same
thing I would do in C and is easier to understand.

Also things like templates are valuable, for example I wrote a FIFO
template.  I debug that template once and never have to write fifo code
again.  This is something very hard to do in C with any efficiency.  Now I
can create a FIFO for uint8_t, uint32_t, or a structure with one line.
This can not be done easy in C. The same is true for circular buffers and

So yea C++ on embedded is very valid and real.   I have been doing
professional embedded C for over 30 years and just switched to C++ and do
not want to go back to C.  The misconceptions about bloat are no longer
valid.  Sure you can write bad C++ code using standard templates and such
but you can also write bad C code, so don't do either. I think the
misconception about C++ is because people try to do stupid stuff like use
cout, new, RTTI, exceptions, etc.  Where most of the time the simple
compile time features of C++ offer huge advantages over C.

At the end of the day all the compile time features of C++ are free, like
classes. There is zero reason not to use them because they are free. The
run time features are not free but you can choose what you use, and turn
off what you don't need.

So yes I can write bad C++ code that is slow and bloated. I can write bad C
code that is slow and bloated. My job is to write functional code that
works and works correctly with no side effects and I can do that faster and
more efficiently in C++ using OO and minimal features of C++.  Maybe others
can not, but that is not my problem.

Note that I have worked on projects in the past where we squeezed every
clock and every byte out of a processor. However I have not had to optimize
for size or speed in 10 years.  That is processors are so cheap and
powerful if you have to optimize code for size or speed then you most
likely picked the wrong microprocessor.

The problem with interrupt handlers which I asked about still exists if you
use C to write the code.  That is you still have to map the interrupt
handler to the correct instance of the object unless you are insane and
write a driver for each UART instance, which talking about bloat and


On Sat, Apr 10, 2021 at 5:12 PM David Kelly <> wrote:

> On Apr 10, 2021, at 2:37 PM, Trampas Stern <> wrote:
> If you guys have a better way I would love to know.
> Don’t use C++?
> What does object-oriented coding do for embedded projects? It’s akin to
> using printf(). Slow and lots of bloat.
> Time once was I put uint32 in a union so as to code ++ inline rather than
> let avr-gcc call a library routine. Even more so if in an interrupt. Not
> all library routines used to be re-entrant.
> --
> David Kelly N4HHE, <>
> ============================================================
> Whom computers would destroy, they must first drive mad.

Reply via email to