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

[Turamnvia Suouriviaskimatta]

I 'm following various posting in "comp.lang. ada, comp.lang.c++ ,
comp.realtime, comp.software-eng" groups regarding selection of a
programming language of C, C++ or Ada for safety critical real-time
applications. The majority of expert/people recommend Ada for safety
critical real-time applications. I've many years of experience in C/C++ (and
Delphi) but no Ada knowledge.

May I ask if it is too difficult to move from C/C++ to Ada?
What is the best way of learning Ada for a C/C++ programmer?

[Randy Brukardt]

"Jerry Coffin" <jc*****@taeus. com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .
....

To be both professional and efficient, how about if we just paste in
the entire text of the LRM before each statement? That would leave
nobody room for _any_ doubt about what the code means. Oh...well,
you're probably right: to go with, we'd better paste in the entire text
of a real dictionary, and (just in case) a complete set of books
teaching how to read English. The people you're obviously targeting as
reading the code undoubtedly need that -- after all, every word in
"Language Reference Manual" has three whole syllables!
That's certainly the process it takes to write a language standard; you have
to decide what every word means, or even specify the dictionary to use if
the word isn't defined in the standard. Ada programmers do care about such
things. It's not unusual to put a reference to the standard (or nowdays, a
link to the standard) into comments of Ada code.

There is an art to how much needs to be explicit, but if in doubt (and when
it comes to non-obvious language rules like precidence or visibility, it's
always in doubt), it is always better to err on the side of explicitness.
Ada advocate: "The world WOULD be better if you used Ada."

And the world IS better because of the various rock solid programs I wrote
in Ada. I suspect that many of the people in comp.lang.ada could and would
say the same.

OTOH, there is a lot of "cool" code out there that crashes systems and adds
security holes. Those things are much less likely in Ada code (certainly not
impossible, of course, especially since we have to sit on top of C-based
OSes).

Randy Brukardt
It's not unusual

[Ludovic Brenta]

"Jerry Coffin" writes:

Dr. Adrian Wrigley wrote:

[ ... ]

Isn't there some confusion here?

Surely the "aliasing" issue (ignored by C++ completely(?)) is
largely independent if the
"reinterpret_ca st"/"Unchecked_Conv ersion" issue?

Yes -- he started by mentioning aliasing, but mostly seemed to be
talking about type punning, so that was what I replied to. The
discussion centered around safety, which is essentially orthogonal
to aliasing.

No, I did insist on aliasing as the main point, and then briefly about
the representation clause that caused two objects to be overlaid.

Aliasing is definitely *not* orthogonal to safety. The coding
standards I have reviewed for avionics, as well as the "Guide for the
use of the Ada programming language in High Integrity Systems" [1] all
discuss how aliasing adversely affects safety. It is important, in
safty-critical software, to understand aliasing: what it is, when it
takes place, and what the consequences are. Performance in this
context is a minor concern compared to predictability of the software.

[1] http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf

--
Ludovic Brenta.

[Randy Brukardt]

<ji************ **@worldnet.att .net> wrote in message
news:11******** *************@o 13g2000cwo.goog legroups.com...
....

Ada does not use the dot notation for calling member methods for
tagged types.

You mean "Ada 95 does not use...".

Ada 2005 provides "prefixed name" notation for calling methods as an option.
This unifies the syntax for tagged type calls, protected type calls, and
task entry calls (and interfaces which can be implemented by any of those
unifies it further).

Randy Brukardt

[Jerry Coffin]

Ludovic Brenta wrote:

[ ... ]

No, I did insist on aliasing as the main point, and then briefly
about the representation clause that caused two objects to be
overlaid.
Well, I just went back and reread your post, and I still don't see it,
but if you think that's what you said, so be it.
Aliasing is definitely *not* orthogonal to safety. The coding
standards I have reviewed for avionics, as well as the "Guide for the
use of the Ada programming language in High Integrity Systems" [1]
all discuss how aliasing adversely affects safety. It is important,
in safty-critical software, to understand aliasing: what it is, when
it takes place, and what the consequences are. Performance in this
context is a minor concern compared to predictability of the
software.

[1] http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf

I read through the reference above, and what it says about aliasing is
basically "We've built a program verification system that doesn't
understand aliasing, so attempting to use our system on code that uses
aliasing won't work."

Perhaps you intended to post some other link?

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Ludovic Brenta]

"Jerry Coffin" writes:

Ludovic Brenta wrote:

[1] http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf

I read through the reference above, and what it says about aliasing
is basically "We've built a program verification system that doesn't
understand aliasing, so attempting to use our system on code that
uses aliasing won't work."

Perhaps you intended to post some other link?

You seem to have mastered techniques to read faster than light :)

The document does not assume any tools to exist; it does not even
mandate the use of any tools. All it says is that aliasing makes
"informatio n flow analysis" and "symbolic execution" difficult. In
other words, it makes it more difficult to prove the correctness of
software. And provability of software is the single most important
concern in safety-critical applications.

In other application domains, of course, aliasing is not so frowned
upon. But this thread is about safety and, as others like Ioannis
have noted, safty does have a cost, e.g. in terms of flexibility.

--
Ludovic Brenta.

[Jerry Coffin]

Adrien Plisson wrote:

[ ... ]

about Air Traffic Control:

C++ Advocate: "The world WOULDN'T be safer if they used C++"
But they did, and do use C++ on regular basis. E.g.:

http://www.barco.com/airtrafficcontr...p?element=1833
Ada Advocate: "The world IS safer, because of the cool system we wrote"

Right -- that's why things like this:

http://www.computing.co.uk/news/1130528

never happen!

Serously though, if you think the ATC system is written exclusively or
even primarily in Ada, you're simply mistaken. It's certainly true that
for some time now, SOME of the new development has been done in Ada,
but it's also true that some of the new development has been done in
C++. It's also true that there's LOTS of ancient code written in things
like JOVIAL.
about buffer overflows:

Ada advocate: "Networks WOULD be more secure if you used Ada"
C++ advocate: "Networks WOULD be more secure if we used Ada"

So far, no C++ advocate seems to have said anything similar to what you
claim, but in a way you're probably right. If we depended on Ada to do
the job, the Internet (for one) would be drastically more secure,
though only because nobody used it! :-) (<- explicit smiley for those
who seem to need them...)

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Martin Dowie]

Jerry Coffin wrote:

But they did, and do use C++ on regular basis. E.g.:

http://www.barco.com/airtrafficcontr...p?element=1833

But the link you give does not say that C++ was used - perhaps it was
(it actually says "...ODS Toolbox does not require special programming
skills in C/C++...").

But it Ada is used on all sorts of traffic systems from air to rail to
GPS. A list of such systems is available at:

http://www.act-europe.fr/aa_lookwho.php

Cheers

-- Martin

[Jerry Coffin]

Ludovic Brenta wrote:

You seem to have mastered techniques to read faster than light :)
Do you believe that the document was unavailable before you posted the
link to it? In fairness, I'm not sure I'd read this exact version
previously though, so when I have a bit more time, I'll probably reread
it more carefully. Having Ada in the title doesn't _necessarily_ rule
out its containing useful information. :-)

[ ... ]
The document does not assume any tools to exist; it does not even
mandate the use of any tools.
Sorry -- I probably should have said "techniques " rather than "tools",
though I _hope_ anybody using these techniques uses tools to do so --
I'm reasonably certain that on any more than a truly trivial system,
doing the job by hand would be exceptionally error prone.

In any case, the "problem" with aliasing isn't in safety per se, but in
verification. Better verification techniques might eliminate the
problem.

Likewise, it should be added that these techniques have problems with a
number of other perfectly valid and legitimate types of programming
that are not necessarily unsafe either.
All it says is that aliasing makes
"informatio n flow analysis" and "symbolic execution" difficult. In
other words, it makes it more difficult to prove the correctness of
software. And provability of software is the single most important
concern in safety-critical applications.
I doubt that, but if it really was true, Ada should almost certainly be
avoided as well -- pure functional programming makes verification
_considerably_ easier (and only in part because eliminating assignments
eliminates the issue of aliasing).
In other application domains, of course, aliasing is not so frowned
upon. But this thread is about safety and, as others like Ioannis
have noted, safty does have a cost, e.g. in terms of flexibility.

I don't agree that safety necessarily has to have a cost in
flexibility. Certainly if Ada was the only way to achieve safety, the
cost would be extreme, but I remain convinced there are other ways.

In fact, much of language design is a matter of not merely balancing
the two (which Ada does reasonably well) but of finding real solutions
that allow flexibility without losing safety. Unfortunately, when Ada
was being designed, the two seem to have been seen as direct tradeoffs,
where increasing one necessarily reduced the other. In some cases, it
looks to me like flexibility was constricted on the simple assumption
that doing so _must_ improve safety, even if nobody knew how.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Wes Groleau]

Martin Dowie wrote:

Jerry Coffin wrote:

Ada advocate: "The world WOULD be better if you used Ada."
C++ advocate: "The world IS better because of the cool code I wrote."

What on earth would the C advocate say!! ;-)

"Oops. Sorry, I'll fix that in a jiffy!"

--
Wes Groleau
"Lewis's case for the existence of God is fallacious."
"You mean like circular reasoning?"
"He believes in God. Therefore, he's fallacious."

[Ioannis Vranos]

>>This is safer, but limiting.

In C++ may want to declare the variable outside the loop,
break out early and use the loop variable. Let me guess: You can't
break out early in Ada, right?

Of course you can!

Can this be done in Ada?
#include <iostream>
#include <vector>
#include <ctime>
#include <algorithm>
int main()
{
using namespace std;

vector<int> vec(1000);

// Seeds the random number generator
srand(time(0));

// Use rand() to fill vector with values
// As you see the operation is entirely safe.
generate(vec.be gin(), vec.end(), rand);

vector<int>::si ze_type i;

// Finds the first index where a value is smaller than 1000
// in low level style
for(i=0; i<vec.size(); ++i)
if(vec[i]<1000)
break;

i==vec.size()? cout<<"No number <1000 was found\n"
:cout<<"Number <1000 found at index "<<i<<"\n";
}

--
Ioannis Vranos

http://www23.brinkster.com/noicys