reasons for preferring C over C++

"Small-chip programmers are better off using C++ instead of C."

Take small-chip as =<256 Kb Flash and <32 kB RAM, down to the smallest 
micro-controller you can think of.

A student of me is looking for reasons that are put forward for 
preferring C over C++ on small chips. (Note: all reasons, not just 
*valid* reasons).

So far he found

- tooling & experience (no C++ available for my chip, no C++ experience)

- semantic distance to the machine code (I can't easily see what code 
this C++ construct will cause)

- C++ stronger typing gets in the way (forces you to write lots of casts)

- the const trap (ultimately you might/will need to cast the cost away)

- errors are harder to locate

Can you suggest more reasons, or sources (pages, articles, books, etc) 
that mention such reason?

PS I am (in the context of this question) NOT interested in

- purely emotionally rants (like: C++ sucks, C rocks)

- whether a reason is valid (please start a different thread for 
discussing this, I'll surely join in).

Wouter van Ooijen

Wouter van Ooijen <wouter@voti.nl> writes:
> A student of me is looking for reasons that are put forward for
> preferring C over C++ on small chips. (Note: all reasons, not just
> *valid* reasons).

http://yosefk.com/c++fqa/

Paul Rubin schreef op 15-Oct-14 7:36 PM:
> Wouter van Ooijen <wouter@voti.nl> writes:
>> A student of me is looking for reasons that are put forward for
>> preferring C over C++ on small chips. (Note: all reasons, not just
>> *valid* reasons).
>
> http://yosefk.com/c++fqa/
>

I'll have him go through it, but I have the impression that the author 
was only half-serious when he wrote most of the items. Which of course 
makes it into a fun reading.

Wouter

On 10/15/2014 10:21 AM, Wouter van Ooijen wrote:
> "Small-chip programmers are better off using C++ instead of C."
>
> Take small-chip as =<256 Kb Flash and <32 kB RAM, down to the smallest
> micro-controller you can think of.
>
> A student of me is looking for reasons that are put forward for preferring C
> over C++ on small chips. (Note: all reasons, not just *valid* reasons).
>
> So far he found
>
> - tooling & experience (no C++ available for my chip, no C++ experience)

Depending on the resources available (on the die), you might not even get
a "full" C for some devices.  Especially legacy devices that predated
the HLL craze (in MPU/MCU's).

> - semantic distance to the machine code (I can't easily see what code this C++
> construct will cause)

IME, this is the primary advantage of C over C++ (but, then again, I primarily
write RT code)

> - C++ stronger typing gets in the way (forces you to write lots of casts)

I consider this a *weakness* of C!  If you are "forced" to make a cast,
you should be thinking a bit more about what you are doing and why the
cast is necessary (it may be -- I'm just commenting that C's "tolerance"
on this often leads to errors that stronger type checking would have caught).
Too often, I see (desktop) apps that "need casts" but the (C) compiler warnings
are ignored.  On closer inspection, often some of these warnings point out
flaws in the code!

> - the const trap (ultimately you might/will need to cast the cost away)
>
> - errors are harder to locate

Yes and no.  A lot of that depends on coding style.

> Can you suggest more reasons, or sources (pages, articles, books, etc) that
> mention such reason?

You could consider the number (and *types*!) of "programmers" fluent in
each.  That can influence your decision.  In small shops, you may *need*
a "hardware guy" to develop your hardware.  He may end up also being tasked
with writing the firmware.

Or, you may have software types, exclusively, who just purchase COTS boards
and modules and just build an application on some "BSP", not caring about the
hardware.

Consider, also, the guys who will be coming AFTER the initial development
("maintenance").

You can also look at library support (if a third party library is/isn't
available in a binding to your language of choice).

Also, how robust the "components" on which you are building your application
(C++ does a better job, in general, at information hiding -- which can be
good, or bad!)

C++ solutions (IME) *tend* to rely on memory allocation far more heavily
(and less "obviously").  E.g., a C implementation shows all allocations
essentially explicitly.  C++ allows anonymous/transitional objects
which appear "between the lines" of your codebase.  If memory is tight
(small processor), youo may not realize these allocations/releases are
happening until your code crashes.

[In C, you have to explicitly perform them -- aside from auto vars, etc. -- so
you are much more aware of them]

> PS I am (in the context of this question) NOT interested in
>
> - purely emotionally rants (like: C++ sucks, C rocks)
>
> - whether a reason is valid (please start a different thread for discussing
> this, I'll surely join in).

On Wed, 15 Oct 2014 19:21:11 +0200, Wouter van Ooijen <wouter@voti.nl>
wrote:

>"Small-chip programmers are better off using C++ instead of C."
>
>Take small-chip as =<256 Kb Flash and <32 kB RAM, down to the smallest 
>micro-controller you can think of.

And you call that "small" :-)

IMHO, for small system, you need to understand what assembly language
constructs will be generated by a C-language construction, even if you
do not intend to write a single line of assembler code.

Of course, this applies for C++ vs C as well. You really need to
understand which constructs are compile time only and which also
generate some executable code on the small platform.

Some innocent looking C++ constructs might be very costly in run time
code and data size.

>A student of me is looking for reasons that are put forward for 
>preferring C over C++ on small chips. (Note: all reasons, not just 
>*valid* reasons).

I think that the best service you could offer the student is to tell
how some C++ functionality is implemented in C/assembly.

On 10/15/2014 11:03 AM, upsidedown@downunder.com wrote:
> On Wed, 15 Oct 2014 19:21:11 +0200, Wouter van Ooijen <wouter@voti.nl>

>> A student of me is looking for reasons that are put forward for
>> preferring C over C++ on small chips. (Note: all reasons, not just
>> *valid* reasons).
>
> I think that the best service you could offer the student is to tell
> how some C++ functionality is implemented in C/assembly.

+42!

This would be a great "exercise"!

Conversely, how C++ can "abbreviate" (syntactically) common sequences
of operations that one might carry out in C (and why this is A Good
Thing or A Bad Thing)

upsidedown@downunder.com schreef op 15-Oct-14 8:03 PM:
> On Wed, 15 Oct 2014 19:21:11 +0200, Wouter van Ooijen <wouter@voti.nl>
> wrote:
>
>> "Small-chip programmers are better off using C++ instead of C."
>>
>> Take small-chip as =<256 Kb Flash and <32 kB RAM, down to the smallest
>> micro-controller you can think of.
>
> And you call that "small" :-)
>
> IMHO, for small system, you need to understand what assembly language
> constructs will be generated by a C-language construction, even if you
> do not intend to write a single line of assembler code.
>
> Of course, this applies for C++ vs C as well. You really need to
> understand which constructs are compile time only and which also
> generate some executable code on the small platform.
>
> Some innocent looking C++ constructs might be very costly in run time
> code and data size.
>
>> A student of me is looking for reasons that are put forward for
>> preferring C over C++ on small chips. (Note: all reasons, not just
>> *valid* reasons).
>
> I think that the best service you could offer the student is to tell
> how some C++ functionality is implemented in C/assembly.

He is reasonably aware of that. What is is to search for is reasons 
people *cite* for preferring C over C++, so his own opinion is (at this 
stage) not the point.

Wouter

Wouter van Ooijen wrote:
> A student of me is looking for reasons that are put forward for
> preferring C over C++ on small chips. (Note: all reasons, not just
> *valid* reasons).
> 
> So far he found
> 
> - tooling & experience (no C++ available for my chip, no C++ experience)

That would be the killer argument for me. There is no point in reasoning
about using C++ if all you have for your chip is a C compiler. (And
there is no point in reasoning about using C if all you have is an
assembler and a crappy gcc 1.x.)

> - semantic distance to the machine code (I can't easily see what code
> this C++ construct will cause)

You can work as close or as far from the machine as you want. It just
takes much more experience in C++ than in C to know what language
constructs cost you what in terms of code and memory. I have written
boot loaders in C++ ("boot loader" as in "configure RAM and flash and
then get that image running ASAP", not "fancy shell prompt with menus
and file system and stuff over serial and TCP").

C's advantage here is that it's a WYSIWYG language: if you want bloated
code, you actually have to write it. In C++, you may get the bloat by
accident if you're not careful. On the other hand, you can write
hundreds of lines of code with dozens of (template) classes that don't
generate a single machine instruction.

A concrete instance of this problem is that it's easier to avoid needing
libraries in C. About the worst function call a C compiler will generate
implicitly is memcpy, memset, or things like long multiply. If you write
C++ as it's meant to be, with destructors and all, you'll easily get
functions into your code (exception handling) that you cannot simply
replace by a three-line *.asm file.

> - C++ stronger typing gets in the way (forces you to write lots of casts)

The only cast you need in C++ that you don't need in C is the
void*->something* cast. And you need fewer void*->something* conversions
in C++ than in C if you translate the "callback + void* pointer" idiom
into a "class with a virtual method".

The thing that gets bazillions of casts into your code is MISRA, not C++ :-)

> - the const trap (ultimately you might/will need to cast the cost away)

This applies to C as well. If you start using it (and you should), you
have to use it everywhere.

> - errors are harder to locate

Some C++ error messages are hard to decipher, but compilers are getting
better.


  Stefan

On 15/10/14 19:21, Wouter van Ooijen wrote:
> "Small-chip programmers are better off using C++ instead of C."
>
> Take small-chip as =<256 Kb Flash and <32 kB RAM, down to the smallest
> micro-controller you can think of.
>
> A student of me is looking for reasons that are put forward for
> preferring C over C++ on small chips. (Note: all reasons, not just
> *valid* reasons).
>
> So far he found
>
> - tooling & experience (no C++ available for my chip, no C++ experience)
>

I'd split that into two reasons, as they are very different issues.

> - semantic distance to the machine code (I can't easily see what code
> this C++ construct will cause)
>
> - C++ stronger typing gets in the way (forces you to write lots of casts)
>
> - the const trap (ultimately you might/will need to cast the cost away)
>
> - errors are harder to locate
>
> Can you suggest more reasons, or sources (pages, articles, books, etc)
> that mention such reason?
>
> PS I am (in the context of this question) NOT interested in
>
> - purely emotionally rants (like: C++ sucks, C rocks)
>
> - whether a reason is valid (please start a different thread for
> discussing this, I'll surely join in).
>
> Wouter van Ooijen


(Before anyone replies here, remember what Wouter asked for - reasons 
without regard to validity!  Some of these here are commonly-believed FUD.)


How about:

C lets you write spaghetti code which is hard to understand, C++ lets 
you write lasagne code which is even worse.

Exceptions are just undocumented gotos.

All other embedded code, such as RTOS's or network stacks, is written in 
C - so you can't work in pure C++.

Templates cause code bloat.

The STL causes code bloat.

Objects in C++ use the heap, and dynamic memory on a small system is bad.

Objects means everything involves at least one pointer (*this), which is 
inefficient on small cpus.

Templates make code unreadable and undebuggable.

You can't use advanced C features, such as VLA's and designated 
initialisers, in C++.

Coding standards insist on ANSI C.




Some quotations from Bjarne Stroustrup might help too 
(<http://en.wikiquote.org/wiki/Bjarne_Stroustrup>) :

Within C++, there is a much smaller and cleaner language struggling to 
get out.

C makes it easy to shoot yourself in the foot; C++ makes it harder, but 
when you do it blows your whole leg off.

On 15/10/14 18:48, Wouter van Ooijen wrote:
> Paul Rubin schreef op 15-Oct-14 7:36 PM:
>> Wouter van Ooijen <wouter@voti.nl> writes:
>>> A student of me is looking for reasons that are put forward for
>>> preferring C over C++ on small chips. (Note: all reasons, not just
>>> *valid* reasons).
>>
>> http://yosefk.com/c++fqa/
>>
>
> I'll have him go through it, but I have the impression that the author was only half-serious when he wrote most of the items. Which of course makes it into a fun reading.

Fun reading, /and/ doesn't affect the validity.

Something similar could be done for C, of course.