Question

Many embedded engineers use c++, but some argue it’s bad because it’s “object oriented”?

Is it true that being object oriented makes it bad for embedded systems, and if so, why is that really the case?

Edit: Here’s a quick reference for those who asked:

so we
prefer people not to use divide …, malloc …, or other object
oriented practice that carry large
penalty.

I guess the question is are objects considered heavyweight in the context of an embedded system? Some of the answers here suggest they are and some suggest they’re not.

Answer 1

Whilst I’m not sure it answers your question, I can summarise the reasons my previous companies source code was pure C.

It’s firstly worth summarising the situation:

• we wanted to write a large amount of “core” code that would be highly portable across a large number of ARM embedded systems (mostly mid-range mobile phones; both smart phones and ones running RTOSs of various ages)
• the platforms generally had a workable C compiler, though some for example didn’t support floating point “double”s.
• in some cases the platform had a reasonable implementation of the standard library, but in many cases it didn’t.
• a C++ compiler was not available on most platforms, and where it was available support for the C++ standard library, STL or exceptions was highly variable.
• debuggers often weren’t available (a serial port you could send debug printfs to was considered a luxury)
• we always had access to a reasonable amount of memory, but often not to a reasonable malloc() implementation

Given that, we worked entirely in C, and even then only a restricted set of C 89. The resulting code was highly portable. We often used object orientated concepts though.

These days “embedded” is a very wide definition. It covers everything from 8 bit microprocessors with no RAM or C compilers upto what are essentially high end PCs (albeit not running Microsoft Windows) – I don’t know where your project/company sits in that range.