reasons for preferring C over C++

Tom Gardner schreef op 15-Oct-14 10:25 PM:
> 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.
>

What I meant that (in my impression at least) being only half-serious 
enabled the author to be much more funny than he could have been if he 
was fully serious.

Wouter

Stefan Reuther schreef op 15-Oct-14 8:44 PM:
> 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.

IIRC the author of that was referring to run-time problems rather than 
compiler errors.

Wouter

David Brown schreef op 15-Oct-14 10:12 PM:
> 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.

True. I lumped them together because the both have nothing to do with 
the language itself. Availablility of libraries (other than the standrad 
libraries) could be added here.

>
>> - 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.
>

I think you fully understand what I am asking for! Although some of your 
quotes fall under "purely emotionally rants", they still represent 
reasons for some persons not to use C++. I strust my student will have 
plenty of material.

Wouter

On 15/10/14 22:28, Wouter van Ooijen wrote:
> Tom Gardner schreef op 15-Oct-14 10:25 PM:
>> 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.
>>
>
> What I meant that (in my impression at least) being only half-serious enabled the author to be much more funny than he could have been if he was fully serious.

There's an English expression that has been around since
1390: "many a truth is spoken in jest". The interesting
question is how many of the author's observations and
statements are valid.

 From my point of view, the answer is "too many". But
then I've long been of the opinion that "if C++ is the
answer, then what was the question?" - and can we
'revisit' the question

Wouter van Ooijen <wouter@voti.nl> writes:
> I think you fully understand what I am asking for! Although some of
> your quotes fall under "purely emotionally rants", they still
> represent reasons for some persons not to use C++. I strust my student
> will have plenty of material.

C++ vs C is such a flame war because C++ really does solve some of C's
problems, but on the other hand it introduces its own problems, so there
are partisans on both sides.  Stepping back, both are terrible, and the
only reason to use C is the highly mature toolchains, availability of
programmers, existing API's that expect it, and tons of legacy code.

Unfortunately it's hard to see good alternatives that got any traction.

On Wed, 15 Oct 2014 19:21:11 +0200, 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)
> 
> - 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

It takes more knowledge of C++ to write really small code for it.  It 
still takes knowledge of C to do the same thing, but C comes with less to 
begin with, and it's more obvious when you use it.

C++ really starts to shine as applications get big.  So even if you can 
use it in a really small application, you're not going to use its 
features to great advantage.  This isn't really a fault of C++, but it 
certainly is a lack of advantage.

-- 
www.wescottdesign.com

On 16.10.14 00:35, Wouter van Ooijen wrote:
> David Brown schreef op 15-Oct-14 10:12 PM:
>> 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.
>
> True. I lumped them together because the both have nothing to do with
> the language itself. Availablility of libraries (other than the standrad
> libraries) could be added here.
>
>>
>>> - 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.
>>
>
> I think you fully understand what I am asking for! Although some of your
> quotes fall under "purely emotionally rants", they still represent
> reasons for some persons not to use C++. I strust my student will have
> plenty of material.

There are exceptionally good responses.

I'd like to add that a serious programmer for small chips must read
and understand the generated assembly code, to avoid nasty surprises.
(I've had enough of them during 50 years of coding ...)

-- 

Tauno Voipio

Wouter van Ooijen <wouter@voti.nl> wrote:
> Can you suggest more reasons, or sources (pages, articles, books, etc) 
> that mention such reason?

For one perspective, have a look at the book "Real-Time C++: Efficient 
Object-Oriented and Template Microcontroller Programming" by Christopher 
Kormanyos. For most of the book he uses an AVR.

The biggest hurdles to using C++ are in my opinion poor compiler support 
and the fact that it is just a vastly more complex language than C. It 
is also still rapidly evolving, and the things you learned ten years ago 
might just not be valid anymore.

-a

On 16/10/14 08:34, Tauno Voipio wrote:
> I'd like to add that a serious programmer for small chips must read
> and understand the generated assembly code, to avoid nasty surprises.
> (I've had enough of them during 50 years of coding ...)

Very true.

I've recently been horrified about the proportion of "programmers"
that haven't got a clue about the basic relationships between what's
source code and what's in the corresponding machine code. By "basic"
I mean giving some /pseudocode/ for a function call with arguments.

Wouter van Ooijen wrote:
> Stefan Reuther schreef op 15-Oct-14 8:44 PM:
>> Wouter van Ooijen wrote:
>>> - errors are harder to locate
>>
>> Some C++ error messages are hard to decipher, but compilers are getting
>> better.
> 
> IIRC the author of that was referring to run-time problems rather than
> compiler errors.

If that is a problem, it is a consequence of the semantic distance to
the machine, as you put it: if a single line of code can generate a few
hundred machine instructions, have a lot of fun debugging what exactly
caused the program to generate a SIGSEGV in the middle of that.

Other than that, if you've made a mess of pointers and structs in C that
won't be a bit easier to debug than if you've made a mess of pointers
and classes in C++.


  Stefan