Re: Teaching new tricks to an old dog (C++ -->Ada)

["Jerry Coffin" <jcoffin@taeus.com>]

Ludovic Brenta wrote:

[ ... ]

> Yes, assembly is the most powerful and flexible language.  That's why
> all compilers emit assembler.

Not so -- machine language is clearly more flexible than asembly
language (especially on machines where an operation can be encoded in
more than one way). Not all compilers emit assemly language output
either. "Powerful" is meaningless WRT a langauge unless you define what
you mean by it in considerably more detail than I've seen thus far in
this thread (or any other, for that matter).

As an aside: an "assembler" is a program that takes input in "assembly
language" and produces an object file as output. Calling the language
"assembler" is roughly equivalent to referring to Ada as "compiler" --
wrong, and to anybody who isn't entirely clueless about the subject at
hand, downright stupid. I realize that for years IBM (among others)
abused the (English) language by referring to the language as
"assembler", but please avoid their mistake.

[ ... ]

> Here, Ada makes it explicit that unsafe programming is taking place.
> First, Obj must be declared as "aliased", which means that two or
> more paths can access it.  In our case, Obj and Obj_As_String are
> the two paths.  This is another of Ada's nice safety-related
> features.  Since aliasing must be made explicit, the reader of the
> program knows up front whether or not aliasing takes place.  The
> reader of a C++ program has no such knowledge.

Nonsense -- in C++ you use a reinterpret_cast, which is equally
explicit about what's being done. If somebody reading C++ doesn't
recognize what a reinterpret_cast means, then he simply doesn't know
C++.

> Also, the writer of the program must
> think twice, and understand the consequences if they make an object
> aliased.

Anybody who uses a reinterpet_cast without a second (and third) thought
simply isn't a programmer, and of he wrote Ada instead, it'd still be
garbage.

> Secondly, the representation clause for Obj_As_String ("for
> Obj_As_String'Address use ...") says exactly what is happening.

Anybody who thinks that (for example):

unsigned char *a = reinterpret_cast<char *>(&x);

doesn't state exactly what it happening, simply doesn't know C++.

Any language (programming or otherwise) is foreign to those who don't
know that language. It may well be that you don't realize what it
means, and that's perfectly fine -- but assuming it must be inexact
because you don't know exactly what it means is considerably less fine.

> I could make the code less verbose by using use clauses, similar to
> "using namespace std" which you seem fond of.  In avionics, our
> coding standards forbid that because we want everything to be
> explicit.

A poor idea. Just for example, consider writing a generic sorting
function. It needs to swap items that it's sorting. In well-written
C++, this will often be done with a using clause. Specifically, if the
type of items has provided its own specialized version of swap, then my
sorting functino should use that, but otherwise it should use std::swap
to swap them.

If I try to specify whatever_type::swap(x,y), then compilation will
fail if the type has not provided a swap function. Conversely, if I
specify std::swap(x,y), then the specialized swap function won't be
used for those types that provide one.

The solution is something like:

using namespace std;

template<class T>
void sort // ...

// ...
    swap(x,y);

and now, thanks to Koenig lookup, this will refer to a swap
specifically for the type of x and y if there is one, but will use the
swap in the standard library for those (many) types that don't provide
special swapping code.

[ ... ]

> > Someone who places much hopes on the language to protect him from
> > his mistakes, probably ADA is better than C++ on this.
>
> Hear, hear!

Actually, having used both (as well as Verilog and VHDL, which are
based fairly close on C and Ada respectively) I'm not particularly
convinced this is true.

Personally, I think the _vast_ majority of the safety of Ada is an
illusion. In the end, code that works well is a product of a good
programming doing his job well, NOT of a particular language.

Now, it's certainly true that people can (and frequently do) cite
statistics showing that code written in Ada has fewer bugs, etc., as
proving that the language is safer. Even assuming the citations are
correct (which I'm not sure is true, but for the moment, let's assume
they are), they don't necessarily prove that -- or much of anything
else, for that matter.

The problem is that the reputation of a language tends to become a
self-fulfilling prophecy. Managers who are running safety critical
projects often choose Ada because they "know" it's safer -- and then
run their projects in ways that would assure solid results, regardless
of implementation language.

Likewise, programmers who are strongly attracted toward disciplined
software engineering, will often be attracted to Ada because it has
that reputation (and to an extent, that "feeling" as well).

At the opposite extreme, the managers who are most interested in
pushing a product out the door in minimal time and don't mind bugs,
rarely choose Ada -- and run their projects in ways that would produce
buggy products regardless of language. Likewise, the "cowboy"
programmers never learn Ada at all -- as soon as they learn of its
reputation, they avoid it like the plague.

As such, showing causation (rather than mere correlation) becomes
essentially impossible at best -- and here in the real world, the truth
could even be exactly the opposite of what the statistics "prove."

Then again, all of the above should probably be taken with a large
grain of salt. That wouldn't necessary if what I'd been consuming for
the last couple of hours was salt, but thanks to Warren Winiarski, that
wasn't the case... :-)

--
    Later,
    Jerry.

The universe is a figment of its own imagination.