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

Op Sun, 19 Oct 2014 01:07:06 +0200 schreef glen herrmannsfeldt  
<gah@ugcs.caltech.edu>:
> Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>
> (snip)
>
>> The major disadvantage of "extra verbiage" is that the advantages
>> are lost in cases in which it is automatically inserted or
>> the programmer does "whatever is necessary to shut the compiler up".
>> Nothing can help in that latter case.
>
> Reminds me that Java requires the compiler to be able to determine
> that a scalar variable is given a value before it is referenced.
> They could have just zeroed all of them, but that is pretty much
> your "automatic".  This way, you have a chance to think about it.
> But then again, you can just put =0 on all your declarations.

Unless they are "final"!  When poking in other folks' code, I find it  
helps to make things final/const when you think they should be, and see  
where things break.


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

On 14-10-20 07:02 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> I'm curious to know why you feel that the Zeigler article is from a
>> "pro-Ada perspective". 
> 
> Well, ok, I got both links from a pro-Ada site (adahome.com).  It's been
> a while since I read the Ziegler article but its conclusion was
> favorable to Ada.

Ok -- I thought you meant a "pro-Ada perspective" in the sense of being
biased or slanted in favour of Ada, but I misunderstood you.

This reminds me of a post on comp.lang.ada, several years ago. The
poster, who was a student, was tasked with writing a seminar
presentation or an essay (I forget which) comparing the relative
benefits of C and Ada, and wanted to present a "balanced view" but was a
bit desperate because all available reports were in Ada's favour...
IIRC, the people on comp.lang.ada could not help the poster find any
articles reporting comparisons favorable to C. That doesn't prove
anything, of course.

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

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

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.

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

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.

On 2014-10-20, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>
> This reminds me of a post on comp.lang.ada, several years ago. The
> poster, who was a student, was tasked with writing a seminar
> presentation or an essay (I forget which) comparing the relative
> benefits of C and Ada, and wanted to present a "balanced view" but was a
> bit desperate because all available reports were in Ada's favour...
> IIRC, the people on comp.lang.ada could not help the poster find any
> articles reporting comparisons favorable to C. That doesn't prove
> anything, of course.
>

The only positive thing in favour of C is that the C compilers will
generate code for, and run on, a lot more targets and platforms than
the Ada compilers will.

As Niklas is probably aware, this is a _major_ annoyance of mine
because it means you can't write portable library code in Ada which
will be guaranteed to run in a large range of environments, especially
embedded ones. However, you do have this assurance with C code.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Simon Clubley wrote:
> On 2014-10-20, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>>
>> This reminds me of a post on comp.lang.ada, several years ago. The
>> poster, who was a student, was tasked with writing a seminar
>> presentation or an essay (I forget which) comparing the relative
>> benefits of C and Ada, and wanted to present a "balanced view" but was a
>> bit desperate because all available reports were in Ada's favour...
>> IIRC, the people on comp.lang.ada could not help the poster find any
>> articles reporting comparisons favorable to C. That doesn't prove
>> anything, of course.
>>
>
> The only positive thing in favour of C is that the C compilers will
> generate code for, and run on, a lot more targets and platforms than
> the Ada compilers will.
>
> As Niklas is probably aware, this is a _major_ annoyance of mine
> because it means you can't write portable library code in Ada which
> will be guaranteed to run in a large range of environments, especially
> embedded ones. However, you do have this assurance with C code.
>
> Simon.
>

Aren't there Ada toolchains that emit as a target language 'C'? That 
would at leas allow tweaking #pragmas and such to get thing shoehorned 
into the toolchain.

-- 
Les Cargill

Les Cargill wrote:

> Aren't there Ada toolchains that emit as a target language 'C'? That
> would at leas allow tweaking #pragmas and such to get thing shoehorned
> into the toolchain.

There exists one such Ada compiler that I know of (and possibly two more
I've heard rumors of).  The one I know of (AdaMagic) is rather
expensive, so I've never actually used it for a project.  So far, it has
been cheaper to spend the extra time writing C myself.

Greetings,

Jacob
-- 
"Facts are stubborn, but statistics are more pliable." -- Mark Twain

Jacob Sparre Andersen wrote:
> Les Cargill wrote:
>
>> Aren't there Ada toolchains that emit as a target language 'C'? That
>> would at leas allow tweaking #pragmas and such to get thing shoehorned
>> into the toolchain.
>
> There exists one such Ada compiler that I know of (and possibly two more
> I've heard rumors of).  The one I know of (AdaMagic) is rather
> expensive, so I've never actually used it for a project.  So far, it has
> been cheaper to spend the extra time writing C myself.
>

Ah. Oh well. Isn't that just the story of Ada, though? We've
always been too cheap to buy it.

> Greetings,
>
> Jacob
>

-- 
Les Cargill