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

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

validity of ... reasons for preferring C over C++

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

Contents

  validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-17 00:00 +0100
    Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 07:38 +0200
    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 09:27 +0200
      Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 09:29 +0100
        Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 11:19 +0200
          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 02:35 -0700
            Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 11:43 +0200
              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:12 +0100
                Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 13:25 +0200
                  Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:40 +0100
              Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 20:12 +0300
                Re: validity of ... reasons for preferring C over C++ Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-17 10:18 -0700
                  Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-17 21:53 +0300
                    Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 22:59 +0300
                      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 13:23 -0700
                        Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-18 17:46 +0200
                          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-18 11:45 -0700
                            Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 01:51 +0300
                              Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-19 12:43 +0200
                  Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-18 17:44 +0200
            Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 12:44 +0200
              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:13 +0100
              Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-17 20:15 +0300
                Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 19:18 +0200
                Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 23:03 +0200
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-17 14:11 -0700
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-18 20:14 +0200
                      Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:15 +0100
                        Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-18 23:07 +0000
                          Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-19 00:36 +0100
                            Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 10:55 +0300
                              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-19 09:33 +0100
                          Re: validity of ... reasons for preferring C over C++ "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2014-10-20 15:04 +0200
                        Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-19 13:32 +0200
                  Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 23:44 +0200
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-18 20:10 +0200
                      Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-18 23:38 +0300
                      Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 22:21 +0100
                  Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 10:43 +0300
                    Re: validity of ... reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-19 09:38 +0000
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-19 14:07 +0200
                      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 19:47 -0700
                        Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-20 06:55 +0300
                          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-19 21:02 -0700
                            Re: validity of ... reasons for preferring C over C++ britt.snodgrass@gmail.com - 2014-10-20 04:02 -0700
                            Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-20 18:51 +0300
                              C and Ada, was: Re: validity of ... reasons for preferring C over C++ Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2014-10-21 00:30 +0000
                                Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-20 20:49 -0500
                                  Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2014-10-21 09:11 +0200
                                    Re: C and Ada, was: Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-21 08:34 -0500
                  Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-19 21:23 +0300
                  Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-20 03:39 +0100
            Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:07 +0100
          Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 12:06 +0100
            Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-17 14:12 +0200
              Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 13:16 +0100
            Re: validity of ... reasons for preferring C over C++ Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2014-10-17 14:13 +0200
              Re: validity of ... reasons for preferring C over C++ Arlet Ottens <usenet+5@c-scape.nl> - 2014-10-17 14:35 +0200
                Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-17 13:59 +0100
              Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-17 17:06 +0200
              Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-17 19:41 +0300
        Re: validity of ... reasons for preferring C over C++ Clifford Heath <no.spam@please.net> - 2014-10-18 10:14 +1100
          Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 00:36 +0100
            Re: validity of ... reasons for preferring C over C++ Clifford Heath <no.spam@please.net> - 2014-10-20 09:45 +1100
          Re: validity of ... reasons for preferring C over C++ Niklas Holsti <niklas.holsti@tidorum.invalid> - 2014-10-18 08:52 +0300
            Re: validity of ... reasons for preferring C over C++ Tom Gardner <spamjunk@blueyonder.co.uk> - 2014-10-18 09:41 +0100
    Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-20 09:46 -0700
      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-20 16:26 -0700
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-20 16:42 -0700
          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-20 17:24 -0700
            Re: validity of ... reasons for preferring C over C++ John Devereux <john@devereux.me.uk> - 2014-10-21 19:09 +0100
              Re: validity of ... reasons for preferring C over C++ Wouter van Ooijen <wouter@voti.nl> - 2014-10-24 16:38 +0200
            Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:12 -0700
              Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-21 16:39 -0700
                Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-22 01:43 +0100
                Re: validity of ... reasons for preferring C over C++ Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-22 20:00 +0200
            Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 18:49 +0200
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:15 -0700
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-22 04:45 -0700
          Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-22 09:30 -0700
            Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-23 12:25 -0700
              Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-23 15:17 -0700
                Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-23 22:59 +0000
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-23 16:02 -0700
                Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-27 08:30 -0700
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-27 09:00 -0700
                    Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-27 09:24 -0700
                      Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-27 09:30 -0700
                      Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-28 00:52 +0000
                Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-28 08:45 +0100
                  Re: validity of ... reasons for preferring C over C++ Paul Rubin <no.email@nospam.invalid> - 2014-10-28 02:00 -0700
                    Re: validity of ... reasons for preferring C over C++ George Neuner <gneuner2@comcast.net> - 2014-10-30 11:56 -0400
                  Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-28 19:59 +0200
                    Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-28 23:46 +0100
                      Re: validity of ... reasons for preferring C over C++ upsidedown@downunder.com - 2014-10-29 07:27 +0200
                        Re: validity of ... reasons for preferring C over C++ David Brown <david.brown@hesbynett.no> - 2014-10-29 10:11 +0100
                    Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-29 10:21 -0500
                      Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-29 20:15 +0000
                        Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-30 11:33 -0500
                          Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-30 19:07 +0000
                            Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-30 16:19 -0500
                        Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-31 07:32 +0000
                          Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 08:45 +0000
                            Re: validity of ... reasons for preferring C over C++ Reinhardt Behm <rbehm@hushmail.com> - 2014-10-31 18:15 +0800
                              Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 22:03 +0000
                            Re: validity of ... reasons for preferring C over C++ Robert Wessel <robertwessel2@yahoo.com> - 2014-10-31 09:53 -0500
                              Re: validity of ... reasons for preferring C over C++ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-31 22:17 +0000
                          Re: validity of ... reasons for preferring C over C++ Les Cargill <lcargill99@comcast.com> - 2014-10-31 17:50 -0500
              Re: validity of ... reasons for preferring C over C++ Nobody <nobody@nowhere.invalid> - 2014-10-28 04:37 +0000
      Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-21 19:12 +0200
        Re: validity of ... reasons for preferring C over C++ Dave Nadler <drn@nadler.com> - 2014-10-21 15:06 -0700
          Re: validity of ... reasons for preferring C over C++ Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 19:06 +0200

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#18729

On Fri, 17 Oct 2014 14:13:55 +0200, Stef
<stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

>On 2014-10-17 Tom Gardner wrote in comp.arch.embedded:
>>
>> I've forgotten the name for the generic phenomenon that the ignorant
>> think they are better than they actually are. If anyone
>> can come up with a decent way of allowing people to realise what
>> they don't know, then they have probably found a way of making
>> themselves very famous, rich, and winning all sorts of prizes.
>
>Ignorance is Bliss?

What is wrong with BLISS ?

It was a nice intermediate level language, in which much of VAX/VMS
was written. 

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

#18765

On 17/10/14 19:29, Tom Gardner wrote:
> On 17/10/14 08:27, David Brown wrote:
>> If you don't know what your C++ code is doing, that's /your/ problem,
>> not the language's problem.
> Well yes. But some languages do have more obscured traps that
> that require higher levels of skill and more continual alertness.

Sharp tools cut. What's your point?

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

#18766

On 18/10/14 00:14, Clifford Heath wrote:
> On 17/10/14 19:29, Tom Gardner wrote:
>> On 17/10/14 08:27, David Brown wrote:
>>> If you don't know what your C++ code is doing, that's /your/ problem,
>>> not the language's problem.
>> Well yes. But some languages do have more obscured traps that
>> that require higher levels of skill and more continual alertness.
>
> Sharp tools cut. What's your point?

Read the rest of my posting, i.e. the bit you snipped.

If you can't be bothered to do that you are no better
than a troll. Other people have succeeded and we've
had a reasonable discussion. Please don't spoil it unless
you have something to contribute.

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

#18831

On 18/10/14 10:36, Tom Gardner wrote:
> On 18/10/14 00:14, Clifford Heath wrote:
>> On 17/10/14 19:29, Tom Gardner wrote:
>>> On 17/10/14 08:27, David Brown wrote:
>>>> If you don't know what your C++ code is doing, that's /your/ problem,
>>>> not the language's problem.
>>> Well yes. But some languages do have more obscured traps that
>>> that require higher levels of skill and more continual alertness.
>> Sharp tools cut. What's your point?
> Read the rest of my posting, i.e. the bit you snipped.

I did. Here, I'll even respond to some of it:

> K&R C had 228 pages. C Traps and Pitfalls had 228 pages. They
were all you needed in the 80. How long are the modern equivalents?

K&R C massively under-specified the language, even with the extension of 
Traps and Pitfalls. The modern specifications fill out the missing bits, 
and specify the changes that were needed to the language to handle the 
extensive problems that were exposed.

I never said that C or C++ were "nice" or "friendly" languages - in fact 
I agree with Niklas' response entirely. C is important because it's 
"sharp", and some of C++'s features are arguably unnecessary because 
they don't refine that core concept.

You have to learn how to use it. Much of C++ is entirely suitable for 
writing effective programs that do their job succinctly, precisely and 
with a minimum of bloat. The libraries are definitely not designed for 
the embedded environment, so if you skip them (or use them only with 
careful circumspection) you'll do better, but the libraries are not the 
language.

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

#18777

On 14-10-18 02:14 , Clifford Heath wrote:
> On 17/10/14 19:29, Tom Gardner wrote:
>> On 17/10/14 08:27, David Brown wrote:
>>> If you don't know what your C++ code is doing, that's /your/ problem,
>>> not the language's problem.
>> Well yes. But some languages do have more obscured traps that
>> that require higher levels of skill and more continual alertness.
> 
> Sharp tools cut. What's your point?

Even a sharp tool should have a comfortable and safe handle. You don't
want the handle to have surprising sharp edges or to collapse if you
hold it in the wrong way.

As a tool, a programming language has both a "handle" part, which is the
rules and principles of the language, for the programer to "hold" as she
guides the tool by writing programs, and a "sharp edge" part, which is
the running program, which changes the world around it and carves out
the nuggets of desired results from the default chaos.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

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

#18785

On 18/10/14 06:52, Niklas Holsti wrote:
> On 14-10-18 02:14 , Clifford Heath wrote:
>> On 17/10/14 19:29, Tom Gardner wrote:
>>> On 17/10/14 08:27, David Brown wrote:
>>>> If you don't know what your C++ code is doing, that's /your/ problem,
>>>> not the language's problem.
>>> Well yes. But some languages do have more obscured traps that
>>> that require higher levels of skill and more continual alertness.
>>
>> Sharp tools cut. What's your point?
>
> Even a sharp tool should have a comfortable and safe handle. You don't
> want the handle to have surprising sharp edges or to collapse if you
> hold it in the wrong way.
>
> As a tool, a programming language has both a "handle" part, which is the
> rules and principles of the language, for the programer to "hold" as she
> guides the tool by writing programs, and a "sharp edge" part, which is
> the running program, which changes the world around it and carves out
> the nuggets of desired results from the default chaos.

Nicely put, but I hope this doesn't degenerate into a
lot of hot air about dubious analogies!

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

#18853

On Wed, 15 Oct 2014 19:21:11 +0200, Wouter van Ooijen wrote:
> PS I am (in the context of this question) NOT interested in
> - whether a reason is valid (please start a different thread for 
> discussing this, I'll surely join in).

!!! Availability of skilled C++ developers !!!

Here the biggest obstacle has been lack of available
adequately skilled C++ developers. Most applicants
*really* don't know the practical realities of C++,
and failed a programming test we developed (not language
lawyer stuff, rather "if you don't know this you'll
create code that corrupts memory" kinda things).

In the embedded space, think about how many folks
with lots of C++ on their resume could answer:

1) Give some examples where C++ can help you manage
low-level machine access easier than raw C.

2) In a small embedded system with no dynamic memory
(other than the stack):

2a) What language features will you not be able to use?

2b) What special considerations will you expect when
creating a class?

3) Give an example where using C++ a template can generate
more efficient code than typical C coding.

That's off the top of my head, if I were hiring at the
moment I'd give this a bit more thought...

Have you folks had the same experience?
Best Regards, Dave

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

#18856

Dave Nadler <drn@nadler.com> writes:
> In the embedded space, think about how many folks
> with lots of C++ on their resume could answer:

I'm no C++ expert by any means, but I'll try:

> 1) Give some examples where C++ can help you manage
> low-level machine access easier than raw C.

Best I can say is it's easier in C++ to organize the low level
operations into operations on a class encapsulating the raw machine
pointers, so the compiler can catch errors more easily than if you wrote
a bunch of C functions that manipulated the pointers while leaving them
exposed.  Operator overloading can also help abstract low level
operations into higher level ones.  Maybe there's a better answer than
this though.

> 2) In a small embedded system with no dynamic memory
> (other than the stack):
>
> 2a) What language features will you not be able to use?

"new" and "delete" are the basic ones.  A lot of the STL such as
resizeable containers depend on them, as well as standard types like
std::string, though those aren't language features per se.  I think
there may be some issue using C++ exceptions without the dynamic heap
but I'm not sure.

> 2b) What special considerations will you expect when creating a class?

I guess the RAII pattern can't work the same way.  Is there more?

> 3) Give an example where using C++ a template can generate more
> efficient code than typical C coding.

The C library qsort function requires you to pass a comparison method as
a function pointer, so you incur function call overhead even if you're
just comparing integers in what should be a single machine instruction.
The C++ version uses a template so the comparison can be inlined.

> Have you folks had the same experience?

So far I've only used C++ on big machines where I don't mind the code
and memory bloat.  In that situation I think it's an improvement over C.
Especially with C++11 STL and using stuff like shared_ptr freely, you
can program in almost the style of a garbage collected scripting
language while still getting close to C speed.  The error messages from
STL mistakes are pretty incomprehensible, but at least the compiler has
told you something is wrong at a certain line number, so with a bit of
head scratching you can generally figure out the mistake.

Generally though I still think of C++ and C as dangerous legacy
languages.  I'm looking towards modern replacements like Rust
(rust-lang.org) though those aren't really suitable for small embedded
systems because of relatively complex runtimes to support the
concurrency and garbage collection features.

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

#18857

Sorry, I wasn't trying to pose a challenge;
rather wondering if others have also had difficulty
finding qualified help. We've used C++ on some
pretty tiny machines, to good effect...

On Monday, October 20, 2014 7:26:16 PM UTC-4, Paul Rubin wrote:
> So far I've only used C++ on big machines where I don't mind the code
> and memory bloat.

I guess I should add another question:

4) Under what conditions could C++ add code or memory bloat?
How can it help *reduce* code and memory bloat?

Thanks for your thoughts,
Best Regards, Dave

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

#18858

Dave Nadler <drn@nadler.com> writes:
> Sorry, I wasn't trying to pose a challenge; rather wondering if others
> have also had difficulty finding qualified help.

There's lots of C++ programmers around and it's not THAT difficult a
language.  I don't know your situation but around here, "difficulty
finding qualified help" often means "the help I need is available but I
don't want to pay market rates for it".  

That said, I thought your questions were interesting and I don't think
I'd currently pass a serious interview to select knowledgeable C++
programmers.  I've used enough C++ to get some specific tasks done and
studied it a bit out of PL geekery interest, but am not extensively
experienced with it.

> We've used C++ on some pretty tiny machines, to good effect...

Yes, Stroustrup keeps saying that it's perfectly well suited to the
small device space, and there's not a serious reason it shouldn't be,
if you program in a constrained style.  

> 4) Under what conditions could C++ add code or memory bloat?
> How can it help *reduce* code and memory bloat?

The most notorious cause of C++ object code bloat is template
instantiation duplicating the same code all over the place for multiple
types.  Of course the same thing would happen in C if you copied
functions all over, but in practice you'd tend to use some ad hoc
generic scheme with void* casts, function pointer callbacks for what
would be different template expansions, etc.  But, I think the template
generic style only bloats the binary: it actually keeps source code more
concise and duplication-free (DRY principle).

I'd say there's some runtime memory bloat from using STL containers
instead of specialized containers written around your specific data.  I
guess this can be mitigated somewhat with custom allocators though I
haven't had to resort to that.  There's also some memory bloat from the
idiomatic C++ style of passing large objects around by value
(i.e. copying them all over) though maybe that's less needed now that
shared_ptr (poor man's garbage collection) is used more.  There are
now some hooks for actual GC as well, though I haven't used them yet.

I do think using shared_ptr or GC can simplify programs a lot, getting
rid of a lot of complex and bug-prone manual storage management code, at
the expense of sometimes burning more memory than is strictly needed.  I
like Rust's approach of combining good tracking of object ownership
(allowing just-in-time reclamation without GC in a lot of cases) and GC
for when you need it.  I haven't yet used Rust but it's interesting.

Similarly the use of libraries like STL and Boost simplify code by
supplying well-tested, fast implementations of standard data structures
that in C programs end up getting implemented half-assedly over and
over, differently in every program.  That means smaller source code at
the cost of bigger object code, since those libraries pull in code for a
lot of features that you might not use.

I'm hacking on a fairly small C++ program right now that compiles to a
1.2MB binary, which seems ridiculous, like > 10x what it has any
business taking.  So that's an example of object code bloat.  On the
other hand, it's running on a 32GB machine so the 1.2MB is of no
consequence.

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

#18866

Paul Rubin <no.email@nospam.invalid> writes:

> Dave Nadler <drn@nadler.com> writes:
>> Sorry, I wasn't trying to pose a challenge; rather wondering if others
>> have also had difficulty finding qualified help.
>
> There's lots of C++ programmers around and it's not THAT difficult a
> language.  I don't know your situation but around here, "difficulty
> finding qualified help" often means "the help I need is available but I
> don't want to pay market rates for it".  
>
> That said, I thought your questions were interesting and I don't think
> I'd currently pass a serious interview to select knowledgeable C++
> programmers.  I've used enough C++ to get some specific tasks done and
> studied it a bit out of PL geekery interest, but am not extensively
> experienced with it.
>
>> We've used C++ on some pretty tiny machines, to good effect...
>
> Yes, Stroustrup keeps saying that it's perfectly well suited to the
> small device space, and there's not a serious reason it shouldn't be,
> if you program in a constrained style.  
>
>> 4) Under what conditions could C++ add code or memory bloat?
>> How can it help *reduce* code and memory bloat?
>
> The most notorious cause of C++ object code bloat is template
> instantiation duplicating the same code all over the place for multiple
> types.  Of course the same thing would happen in C if you copied
> functions all over, but in practice you'd tend to use some ad hoc
> generic scheme with void* casts, function pointer callbacks for what
> would be different template expansions, etc.  But, I think the template
> generic style only bloats the binary: it actually keeps source code more
> concise and duplication-free (DRY principle).
>
> I'd say there's some runtime memory bloat from using STL containers
> instead of specialized containers written around your specific data.  I
> guess this can be mitigated somewhat with custom allocators though I
> haven't had to resort to that.  There's also some memory bloat from the
> idiomatic C++ style of passing large objects around by value

I have not seen that, c++ programs do tend to pass objects using
*references*, and then the called functions operate on them using the
same syntax "as if" the reference is the object itself. But really it is
just a pointer being passed (as is usual in C also).

Also c++11 has had a lot of work put into efficiently passing objects by
move constructors and so forth, again it is just a pointer changing
AIUI.

> (i.e. copying them all over) though maybe that's less needed now that
> shared_ptr (poor man's garbage collection) is used more.  There are
> now some hooks for actual GC as well, though I haven't used them yet.
>
> I do think using shared_ptr or GC can simplify programs a lot, getting
> rid of a lot of complex and bug-prone manual storage management code, at
> the expense of sometimes burning more memory than is strictly needed.  I
> like Rust's approach of combining good tracking of object ownership
> (allowing just-in-time reclamation without GC in a lot of cases) and GC
> for when you need it.  I haven't yet used Rust but it's interesting.
>
> Similarly the use of libraries like STL and Boost simplify code by
> supplying well-tested, fast implementations of standard data structures
> that in C programs end up getting implemented half-assedly over and
> over, differently in every program.  That means smaller source code at
> the cost of bigger object code, since those libraries pull in code for a
> lot of features that you might not use.
>
> I'm hacking on a fairly small C++ program right now that compiles to a
> 1.2MB binary, which seems ridiculous, like > 10x what it has any
> business taking.  So that's an example of object code bloat.  On the
> other hand, it's running on a 32GB machine so the 1.2MB is of no
> consequence.

I have been playing with embedded c++11, just some toy programs on ARM
microcontroller development boards at the moment. The minimum footprint
was only a few kB, it seems absolutely fine for even the smallest
projects (that I would be interested in anyway). Even using some STL and
vectors and strings and so forth seemed to work without doing anything
too dramatic to the code size.

-- 

John Devereux

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

#18935

>> Yes, Stroustrup keeps saying that it's perfectly well suited to the
>> small device space, and there's not a serious reason it shouldn't be,
>> if you program in a constrained style.

I agree as far as the *language* is concerned, but the standard 
*libraries* are almost useless for a small real-time system. The biggest 
problem that they were created with the desktop mindset: "memory is 
cheap and plenty, average performance is what counts, and resource 
shortage must be met with graceful degradation". This leads to libraries 
that use the heap and exceptions, and have good avarage but bad 
worst-case performance. Exactly what you *don't* want on a small 
rea-time embedded system.

> I have been playing with embedded c++11, just some toy programs on ARM
> microcontroller development boards at the moment. The minimum footprint
> was only a few kB, it seems absolutely fine for even the smallest
> projects (that I would be interested in anyway). Even using some STL and
> vectors and strings and so forth seemed to work without doing anything
> too dramatic to the code size.

My C++ blink-a-led built for the LPC1114 uses 232 bytes code. OK, that 
is without heap, exceptions, and global objects, but I don't want those 
on a small uc anyway.

Wouter van Ooijen

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

#18868

On Monday, October 20, 2014 8:24:14 PM UTC-4, Paul Rubin wrote:
> "difficulty  finding qualified help" often means
> "the help I need is available but I 
> don't want to pay market rates for it".  

Um, some of us know the true cost of finding, hiring, and
integrating (assimilating?) the right staff. Thus we pay
above market to keep them as net costs are lower...

> I'm hacking on a fairly small C++ program right now that compiles to a
> 1.2MB binary, which seems ridiculous, like > 10x what it has any
> business taking.  So that's an example of object code bloat.

Often that's due to including iostreams; have you looked at
the map to see what has been dragged in and why?

Thanks for the thoughts,
Best Regards, Dave

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

#18875

Dave Nadler <drn@nadler.com> writes:
> Often that's due to including iostreams; have you looked at
> the map to see what has been dragged in and why?

Interesting point about iostreams.  I haven't really looked into the
bloat cause.  I know that everything on 64 bit systems is big.  I've
idly thought about compiling the program on a 32 bit system to see if it
comes out smaller.  The philosophy of C++ seems to be to generate fast
code above everything else.  When there is a trade-off between code size
and speed, it will bloat the code to get more speed.  For this
particular program speed is what I want, since it crunches terabytes of
data for weeks at a time, so I haven't worried about the bloat.

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

#18878

On Tue, 21 Oct 2014 16:39:38 -0700, Paul Rubin wrote:

> Dave Nadler <drn@nadler.com> writes:
>> Often that's due to including iostreams; have you looked at
>> the map to see what has been dragged in and why?
> 
> Interesting point about iostreams.  I haven't really looked into the
> bloat cause.  I know that everything on 64 bit systems is big.  I've
> idly thought about compiling the program on a 32 bit system to see if it
> comes out smaller. The philosophy of C++ seems to be to generate fast
> code above everything else.  When there is a trade-off between code size
> and speed, it will bloat the code to get more speed.  For this
> particular program speed is what I want, since it crunches terabytes of
> data for weeks at a time, so I haven't worried about the bloat.

Different compilers will make different trade-offs. If you're compiling
for a 64-bit target, the compiler probably isn't going to worry about a
trifling 1.2 MB when you presumably have upwards of 4 GiB of RAM (why
would you be using a 64-bit OS if you have less than that?).

Similarly, on a desktop/server OS where code is demand-paged, executable
size doen't really matter; if large sections of code aren't used, they
won't get paged in.

I would expect a C++ compiler for an 8-bit or 16-bit microcontroller to
make somewhat different tradeoffs.

Tangentially: for iostreams, each overload of operator<< is a separate
function, so you only need to link the ones which you actually use.
Compare this to printf(), which may end up pulling in an entire floating
point library for the sake of %f etc when you actually only need %s.

Another possible source of bloat is I18N. It's possible that simply using
iostreams is pulling in a chunk of locale/codecvt stuff, even if you'll
only ever be using ASCII and the "C" locale. Embedded compilers typically
provide options to limit supported locales or even just ignore wchar_t
altogether, whereas a desktop system will probably include support for
hieroglyphics, Linear-B and several dialects of Klingon for good measure.

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

#18896

Am 22.10.2014 um 01:39 schrieb Paul Rubin:

> Interesting point about iostreams.  I haven't really looked into the
> bloat cause.  I know that everything on 64 bit systems is big.  I've
> idly thought about compiling the program on a 32 bit system to see if it
> comes out smaller.

Just in case, let me throw in a side note: you almost certainly don't 
have to go as far as compiling "on" a 32-bit system to achieve that.  It 
will be quite sufficient to compile _for_ a 32-bit system.  I.e. all you 
need is a cross-compiler for a 32-bit target platform (e.g. Win32 
instead of Win64).

> The philosophy of C++ seems to be to generate fast
> code above everything else.  When there is a trade-off between code size
> and speed, it will bloat the code to get more speed.

I don't really think that's true for C++ as a language.  It may well be 
a true statement about people programming in C++, though.

There was a time when compiler technology didn't manage to keep up with 
the demands of the C++ language specification.  Template instantiation 
created a whole lot of new and interesting problems, which took quite a 
while to sort out.  Linkers in particular have to be a whole lot better 
than they used to, otherwise the sizes of C++ programs liberally 
utilizing templates would have exploded beyond all reason.

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

#18893

Paul Rubin wrote:
> I'm hacking on a fairly small C++ program right now that compiles to a
> 1.2MB binary, which seems ridiculous, like > 10x what it has any
> business taking.  So that's an example of object code bloat.  On the
> other hand, it's running on a 32GB machine so the 1.2MB is of no
> consequence.

File size or stripped size? C++ tends to have ridiculously long
identifier names, and tons of those. 'std::cout << "foobar"'
instantiates a metric ton of template classes, each of which generates
just a few bytes of code, but a few hundred bytes of symbol names. A C
program simply doesn't have so many symbols (main, printf, that's it).


  Stefan

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

#18869

On Monday, October 20, 2014 7:26:16 PM UTC-4, Paul Rubin wrote:
> > 2b) What special considerations will you expect when creating a class?
> 
> I guess the RAII pattern can't work the same way.  Is there more?

RAII works just fine; the resources are not necessarily just memory.
Think about disabling interrupts, grabbing an IO device, etc.
ctor/dtor RAII pattern works wonderfully for these kinds of things.


Thanks!
Best Regards, Dave

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

#18887

On Monday, October 20, 2014 7:26:16 PM UTC-4, Paul Rubin wrote:
> Dave Nadler <drn@nadler.com> writes:
> > 3) Give an example where using C++ a template can generate more
> > efficient code than typical C coding.
> 
> The C library qsort function requires you to pass a comparison method as
> a function pointer, so you incur function call overhead even if you're
> just comparing integers in what should be a single machine instruction.
> The C++ version uses a template so the comparison can be inlined.

That is at the same time a good and terrible example!
Good because it illustrates the language trade-off.
Bad because in a resource constrained environment,
qsort can chew up more stack than is available.

A few years back I encountered a stack overflow due
to an ill-advised use of qsort. I replaced it with
a templatized heapsort. Later I needed to sort a
2nd type. Not enough flash space for a 2nd template
instantiation, so I changed to a single concrete
instance that takes a pure virtual type wrapper
(which provides count, comparison and swap). The
wrapper hides all access from the heapsort;
effectively a couple function pointers. For each
type to sort, derive a trivial wrapper from the pure
virtual base wrapper, and call the single instance
of the sort template.

All this is reflexive and easy for someone familiar
with C++, and it is really powerful. Its a small
amount of code to do efficient sorting without
code bloat.

But the point of my post was: most applicants aren't
at that level, and will struggle with stuff like
this...

Thanks,
Best Regards, Dave

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

#18891

Dave Nadler <drn@nadler.com> writes:
> Bad because in a resource constrained environment,
> qsort can chew up more stack than is available.

You might have been using a broken implementation of quicksort, that
didn't make sure to sort the smaller partition first in its recursive
step.  That keeps the stack use at O(log N) instead of potentially O(N),
which in some really bad implementations can happen if the vector is
already sorted.

> All this is reflexive and easy for someone familiar with C++ ...
> But the point of my post was: most applicants aren't at that level,
> and will struggle with stuff like this...

It could be that embedded developers tend to be more into hardware than
language geekery.  You could look for programmers with a
functional-programming background (ML or Haskell).  C++ template
generics may make more sense from that perspective.

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

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

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

csiph-web