Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #18652 > unrolled thread

reasons for preferring C over C++

Back to article view | Back to comp.arch.embedded

Contents

  reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 19:21 +0200
    Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-15 10:36 -0700
      Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 19:48 +0200
        Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-15 21:25 +0100
          Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 23:28 +0200
            Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-15 23:40 +0100
    Re: reasons for preferring C over C++ Don Y <this@is.not.me.com> - 2014-10-15 10:58 -0700
    Re: reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-15 21:03 +0300
      Re: reasons for preferring C over C++ Don Y <this@is.not.me.com> - 2014-10-15 11:11 -0700
      Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 20:26 +0200
    Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-15 20:44 +0200
      Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 23:30 +0200
        Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-16 18:19 +0200
          Re: reasons for preferring C over C++ Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-16 23:12 +0200
            Re: reasons for preferring C over C++ Reinhardt Behm <rbehm@hushmail.com> - 2014-10-17 13:25 +0800
            Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-17 18:43 +0200
      Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-18 12:29 +0100
        Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 11:44 -0700
          Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:25 +0100
            Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 15:42 -0700
              Re: reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 11:03 +0300
              Re: reasons for preferring C over C++ Tim Wescott <seemywebsite@myfooter.really> - 2014-10-19 17:46 -0500
                Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 16:28 -0700
                Re: reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-20 02:47 +0100
          Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-19 09:34 +0100
            Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 17:00 -0700
              Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-20 08:50 +0100
                Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-20 11:57 +0100
                  Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-20 12:11 +0100
                  Re: reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-20 22:36 +0300
                    Re: reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-21 00:36 +0000
              Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-20 08:52 +0100
              Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-20 11:56 +0100
          Re: reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-19 10:52 +0200
            Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 17:16 -0700
        Re: reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 23:02 +0000
          Re: reasons for preferring C over C++ "tim....." <tims_new_home@yahoo.co.uk> - 2014-10-19 09:45 +0100
    Re: reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-15 22:12 +0200
      Re: reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-15 23:35 +0200
        Re: reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-15 19:10 -0700
        Re: reasons for preferring C over C++ Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2014-10-16 10:34 +0300
          Re: reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-16 10:10 +0100
    Re: reasons for preferring C over C++ Tim Wescott <tim@seemywebsite.com> - 2014-10-16 01:06 -0500
    Re: reasons for preferring C over C++ Anders.Montonen@kapsi.spam.stop.fi.invalid - 2014-10-16 08:32 +0000
      Re: reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-16 20:54 +0200

Page 1 of 3  [1] 2 3  Next page →

#18652 — 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

[toc] | [next] | [standalone]

#18653

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/

[toc] | [prev] | [next] | [standalone]

#18654

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

[toc] | [prev] | [next] | [standalone]

#18664

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.

[toc] | [prev] | [next] | [standalone]

#18666

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

[toc] | [prev] | [next] | [standalone]

#18669

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

[toc] | [prev] | [next] | [standalone]

#18656

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

[toc] | [prev] | [next] | [standalone]

#18657

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.

[toc] | [prev] | [next] | [standalone]

#18658

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)

[toc] | [prev] | [next] | [standalone]

#18659

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

[toc] | [prev] | [next] | [standalone]

#18661

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

[toc] | [prev] | [next] | [standalone]

#18667

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

[toc] | [prev] | [next] | [standalone]

#18687

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

[toc] | [prev] | [next] | [standalone]

#18692

Am 16.10.2014 um 18:19 schrieb Stefan Reuther:

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

... and consider yourself a lucky bastard if the problem was as brutally 
evident as a SIGSEGV.  Now try debugging a tiny, yet inacceptable 
numerical inaccuracy in such an environment.  Or a random, 
about-once-every-three-hours, timing infraction that's been known never 
to happen when the debugger is attached to the program.


Among computing tools, the programming language C has been said to be 
the analog of a surgical scalpel: it's deceptively small, while 
ultimately very powerful --- and it makes a world of difference whether 
the persion wielding it knows how to handle it or not.  One user may 
save a patient's life with just a few deft cuts, while the other will 
kill someone, most likely himself, even faster, with a single clumsy one.

If I try to extend that analogy in the direction of C++, my imagination 
tries to bring up some nightmarish contraption like a handheld, 
large-diameter buzz saw with scalpel blades for teeth, a 20 kW engine 
and nitro-glycerine for fuel: I can accept that might be a very useful 
tool to someone who could manage to operate it safely, but I can't make 
myself believe that anyone ever could.  Not even with all kinds of 
safe-guard mechanisms added to the design.

[toc] | [prev] | [next] | [standalone]

#18697

Hans-Bernhard Bröker wrote:

> Am 16.10.2014 um 18:19 schrieb Stefan Reuther:
> 
>> 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.
> 
> ... and consider yourself a lucky bastard if the problem was as brutally
> evident as a SIGSEGV.  Now try debugging a tiny, yet inacceptable
> numerical inaccuracy in such an environment.  Or a random,
> about-once-every-three-hours, timing infraction that's been known never
> to happen when the debugger is attached to the program.
> 
> 
> Among computing tools, the programming language C has been said to be
> the analog of a surgical scalpel: it's deceptively small, while
> ultimately very powerful --- and it makes a world of difference whether
> the persion wielding it knows how to handle it or not.  One user may
> save a patient's life with just a few deft cuts, while the other will
> kill someone, most likely himself, even faster, with a single clumsy one.
> 
> If I try to extend that analogy in the direction of C++, my imagination
> tries to bring up some nightmarish contraption like a handheld,
> large-diameter buzz saw with scalpel blades for teeth, a 20 kW engine
> and nitro-glycerine for fuel: I can accept that might be a very useful
> tool to someone who could manage to operate it safely, but I can't make
> myself believe that anyone ever could.  Not even with all kinds of
> safe-guard mechanisms added to the design.

It was Chuck Moore who said about his FORTH language that it is an amplifier 
for the abilities of the programmer, the good as well the bad.
C++ i just the bigger hammer. Given to someone who knows what to do, it's 
just the stronger tool, given to the wrong people they create the bigger 
disaster.
C++ has more features to misuse and people who barely understand the basic 
concepts immediately jump on using the newest feature.
For good reason MISRA or DO178 do not allow many of the fancy features.

I am using C, C++ and assembler for safety critical code. Using the features 
of C++ wisely it helps to write clear, correct programs and the overhead is 
negligible.

The reason not to use C++ are mainly the unavailability of a decent compiler 
for smaller micros. And not everything is ARM with megabytes of RAM and ROM, 
sometimes there is just 1k of RAM.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#18736

Hans-Bernhard Bröker wrote:
> Am 16.10.2014 um 18:19 schrieb Stefan Reuther:
>> 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.
> 
> ... and consider yourself a lucky bastard if the problem was as brutally
> evident as a SIGSEGV.  Now try debugging a tiny, yet inacceptable
> numerical inaccuracy in such an environment.  Or a random,
> about-once-every-three-hours, timing infraction that's been known never
> to happen when the debugger is attached to the program.

Last time I had that was in C, and was fixed by -ffloat-store :-)

> Among computing tools, the programming language C has been said to be
> the analog of a surgical scalpel: [...]
> 
> If I try to extend that analogy in the direction of C++, my imagination
> tries to bring up some nightmarish contraption like a handheld,
> large-diameter buzz saw with scalpel blades for teeth, a 20 kW engine
> and nitro-glycerine for fuel: [...]

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


   Stefan

[toc] | [prev] | [next] | [standalone]

#18791

"Stefan Reuther" <stefan.news@arcor.de> wrote in message 
news:m1mmar.23s.1@stefan.msgid.phost.de...
> 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.

me too.

A few weeks ago I was put forward for a job requiring:

extensive low level embedded experience in writing code in resourced limited 
environments, specifically ARM Cortex chipsets (tick, tick, tick)

The project turned out to be a "bionic" watch - no not one that turn into a 
human being, one that monitors your biometrics.

I though "great that sound really me", and then they revealed we are a 
hardcode C++ shop (because some of their other products are advantaged by 
that) and you're going to have to do an online test.

My C++ experience is limited to the embedded environment and I'm up to speed 
on creating OO class structures but not much else.  I don't do standard 
library stiff (just like I don't carry the C library manual around in my 
head), streams or containers.  These things don't seem to have much place 
low level embedded code, but if you believe different fell free to explain 
why

And guess what, the test was 80% on these types on things and predictably, I 
failed.

Looks like they are going to get the employee (well freelancer) that they 
deserve

tim







 

[toc] | [prev] | [next] | [standalone]

#18802

"tim....." <tims_new_home@yahoo.co.uk> writes:
> My C++ experience is limited to the embedded environment and I'm up to
> speed on creating OO class structures but not much else.  I don't do
> standard library stiff (just like I don't carry the C library manual
> around in my head), streams or containers.  These things don't seem to
> have much place low level embedded code, but if you believe different
> fell free to explain why

If you mean STL containers, yes they are useful in all but the smallest
environments and (to a limited extent) even in those.  They will do
stuff like automatic resizing and range checking, and they allow you to
use containers of multiple types without having to paste code all over
the place.  OO on the other hand has become somewhat unfashionable in
C++.

I think it's sufficient to just get a recent C++ book as STL is not
really hard to use.  cppreference.com is also pretty good.  And if it
was an online test you took, unless it said otherwise I'd think it was
ok to use reference materials while taking the test.

[toc] | [prev] | [next] | [standalone]

#18808

On 18/10/14 19:44, Paul Rubin wrote:
> "tim....." <tims_new_home@yahoo.co.uk> writes:
>> My C++ experience is limited to the embedded environment and I'm up to
>> speed on creating OO class structures but not much else.  I don't do
>> standard library stiff (just like I don't carry the C library manual
>> around in my head), streams or containers.  These things don't seem to
>> have much place low level embedded code, but if you believe different
>> fell free to explain why
>
> If you mean STL containers, yes they are useful in all but the smallest
> environments and (to a limited extent) even in those.  They will do
> stuff like automatic resizing and range checking, and they allow you to
> use containers of multiple types without having to paste code all over
> the place.

My knowledge is very out of date and probably plain wrong,
but although /you/ don't have to make duplications in the
source code, doesn't the /compiler/ have to expand them in
the object code.

> OO on the other hand has become somewhat unfashionable in C++.

Probably because they seen "objects done right" in other
languages! :)

[toc] | [prev] | [next] | [standalone]

#18809

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> use containers of multiple types without having to paste code all
>> over the place.
> but although /you/ don't have to make duplications in the
> source code, doesn't the /compiler/ have to expand them in
> the object code.

C++ templates do work like that, so you indeed get bloat in the object
code (just as if you'd manually duplicated code like you'd have to in
C), but the source code becomes more uniform and maintainable.  The
bloat isn't a law of nature but rather reflects C++'s design goal of
zero-overhead abstraction.  

Other languages like Haskell can avoid the bloat by supporting
polymorphic functions implemented by passing type info at runtime,
taking a slight penalty in speed.  I'm not sure how Ada handles this.
Ada has generic but I don't know how they work.  There's also some
generics in C11 or C14 that looked nice though I don't remember any
details by now.  

>> OO on the other hand has become somewhat unfashionable in C++.
> Probably because they seen "objects done right" in other
> languages! :)

No I mean at least among some PL geeks, OO has become unfashionable in
general, not just in C++.  They see it as a 1990's thing that didn't
fulfill its promises.  Smalltalk has faded to obscurity and Java is a
post-Cobol Cobol, etc.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web