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?

[Mark Lorenzen]

Matthias Kaeppler <no****@digital raid.com> writes:

[snip]

Strange... I find that the OO facilities integrate very well in the
non-OO part of Ada. Maybe it is because you look at it from an outside
perspective.

Ada is also -- compared to e.g. C++ -- extremely limiting in terms of
flexibility (which is a good thing for safety critical environments I
guess).

You can do everything in Ada that you can in C and C++. It is more
work in Ada to "force" things together than in C++. So Ada is not as
forgiving, when you have a bad design to begin with.

Regards,
- Mark Lorenzen

[Peter Koch Larsen]

"Ludovic Brenta" <lu************ @insalien.org> skrev i en meddelelse
news:87******** ****@insalien.o rg...

Peter Koch Larsen writes:

Out of curiosiy, could you give some few examples where Ada catches
faults not found by a C++ compiler. I assume - of course - code
written in modern C++: no casts, functions instead of macroes, a
limited use of pointers and so on.
Generally speaking, the very fact that you feel an urge to distinguish
between "C++" and "modern C++" is an indication that C++ is a poor
language containing many unsafe features, some of which you obligingly
enumerated above. By contrast, there is no distinction between "Ada"
and "modern Ada". Ada is safe by design, from the ground up.

We agree here. C++ is a "hackers language", in part because of its C roots.

Now for one specific example, I wrote a buffer overflow in a C++
library a few years ago, and it took me and two other people 3 days to
find it. The fix was, of course, trivial once the bug was found. As
it turned out, this particular bug would have been impossible to write
in Ada. I can't post the code, as it is proprietary and I don't have
it at hand anyway, but the gist of it is that, in Ada, loop variables
(a) are constants and (b) do not exist outside of the loop:

procedure Proc (A : in String) is
begin
for J in A'Range loop
J := J + 4; -- illegal, J is constant inside the loop
end loop;
Do_Womething_Wi th (J); -- illegal, J no longer exists
end Proc;
This is inherited from Pascal if I remember correctly. Of course, good C++
style is to declare your variable in the loop.
Also notice that, in Ada, the "for" statement declares the loop
variable automatically.

The bug in the C++ library was that I was mistakenly reusing the loop
variable after the loop, instead of the intended variable. Of course,
the loop variable was an index pointing after the end of the buffer.

Some other features that make Ada inherently safer than C++ are:

* assignment is not an operator; it is an operation which does not
return a value. Thus, bugs like "if (something = 0)" cannot exist.

* case statements (Ada's equivalent of a switch in C++) are required
to handle all possible cases. Thus it is impossible to forget one.
And, of course, there is no "break;" crap in Ada.

* conditions cannot mix "and" and "or" without parentheses. Thus
there is no possibility that the programmer make wrong assumptions
about precedence of operators or order of evaluation.
This seems ridiculous. I would expect a programmer to know the precedence
rules or at least insert parentheses if they are in doubt.

* the type system, when used appropriately, makes it possible for the
compiler to find semantic errors in addition to just syntax errors.
For example, you can declare that Numers_Of_Apple s and
Numers_Of_Orang es cannot be mixed. This is not possible with C++'s
typedef.
I like that idea. It is possible using templates, of course. Is it general
enough? If you replace "apples" with "weight" and "oranges" with "length",
is it then permissible to multiply a length with a weight but not add the
two together?

* conversions from floating point to integer types involve rounding.
The rounding is precisely and deterministical ly defined by the ISO
standard for the Ada language. Similarly, floating-point and
fixed-point types can be declared with known, deterministic,
guaranteed precision.
This point sounds as if it restricts the environments where Ada can be used.
* pointer types cannot be converted to one another. You cannot
convert a pointer-to-String to a pointer-to-random-object.
You can't do so in C++ either. (C has the conversion to/from void*).

* accessibility rules are rather complex, but they are designed to
minimise the chance of mistakes. Basically, the scope of a pointer
type must be included in the scope of the pointed-to type. This
makes many mistakes impossible, such as returning a pointer to an
object which no longer exists.
I like that one to.

* when the compiler cannot check some code statically, it inserts
run-time checks which are guaranteed to catch all errors by raising
exceptions. In C++ you must code these checks by hand, and of
course at some point you'll forget one crucial check which will cost
you days in debugging.
I sort of like this one as well - although raising an exception seems to be
to forgiving.
My conclusion is that there are some nice ideas out there, but that they
mainly protect against the "sloppy" programmer.

--
Ludovic Brenta.

Thanks for your answer
Peter

[Martin Krischik]

He Peter,

Peterath Larsen wrote:

Out of curiosiy, could you give some few examples where Ada catches faults
not found by a C++ compiler. I assume - of course - code written in modern
C++: no casts, functions instead of macroes, a limited use of pointers and
so on.

Well that's easy:

unsigned int X = -1;

char Y [10];
Y [10] = "X";

Or bit more subtle:

unsigned int X Day_Of_Month = 32;

Now, here as examples all bugs are easy to spot and the compiler might even
show a warning. But now imagine the same with say 200 lines of code in
between - or declaration in one file and assignment in another - and
prehaps a function call instead of an constant expression - and you find
yourself having fun with a debugger.

Martin
--
mailto://kr******@users. sourceforge.net
Ada programming at: http://ada.krischik.com

[Pascal Obry]

"EventHelix.com " <ev********@gma il.com> writes:

What specific features are you missing in C++. Before moving
to Ada consider this:

- It will be hard to find developers for Ada
This is generally not true. It is true that there is less Ada developers than
C++ but there is enough for the demand. I have never had problems finding Ada
developers for my projects.
- You might end up making more mistakes with Ada because of
inexperience with Ada.
Leaning curve in Ada is not as steep as for C++. Of course a beginner will
never be as good as an experienced programmer in whatever language. But Ada
has less traps than other languages on the market. The compiler will help
catch lot of them...
- Ada tools will fall short of the extensive set of C++ related tools.

That's a good point to keep in mind. Even if it easy to build binding to
existing libraries in C/C++ this will require some times.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

[Martin Dowie]

Peter Koch Larsen wrote:

I sort of like this one as well - although raising an exception seems to be
to forgiving.
My conclusion is that there are some nice ideas out there, but that they
mainly protect against the "sloppy" programmer.

Which the world is full of... :-(

It would be fine if the world only needed a couple of dozen good
programmers, the cream would rise to the top and make very few mistakes
and all our software could be written in the most forgiving language in
the world and it would not matter.

But, of course, the world needs 100's of thousands (millions?) of
programmers and they all have varying degrees of ability from the Guru's
and God's to Joe Bloggs, who taught himself (badly) at home and is hired
by his mates dad because he knew he was "into computers" and so on.

Cheers

-- Martin

[Ed Falis]

On Sat, 05 Mar 2005 10:24:19 -0500, Jeff C <jc****@yahoo.c om> wrote:

Finally, I recommend that after about 48/72 hours you put this thread in
a kill file because I find it hard to believe that a cross-posted
question like this is not going to turn into a flame fest.

Interestingly, it hasn't so far.

Since I'm in the business of providing Ada for safety-critical apps, I'll
make few comments just to try to redeem that last one.

One of the big issues with both Java and C++ for safety-critical apps
seems to be that there hasn't been much accomplished to define suitable
subsets for high levels of certification. (I'm aware of the embedded
C++ effort, and of some work on the Java side - someone from Aonix may
want to comment on the latter). In contrast, a lot was done in Ada based
on projects like the Boeing 777 in the early 90's, and Ada subset
definition is currently in a "second generation" that is less restrictive,
more amenable to reuse of existing code bases (despite more strict
interpretation of certification standards), and often oriented towards IMA
architectures (a la ARINC-653).

Anyway, the upshot is that there's a lot of experience fielding
applications written in Ada at high levels of safety certification, and
that should count for something.

- Ed

[Dmitry A. Kazakov]

On Sat, 5 Mar 2005 17:52:36 +0000 (UTC), Martin Dowie wrote:

... Joe Bloggs, who taught himself (badly) at home ...

I don't think that he would be the worst possible choice. Look, if somebody
has a desire to be taught (+5 points), and is ready to do it by himself
(+20!), at his spare time at home (+100!). That's far above the average. I
saw much worse cases!

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Martin Dowie]

Dmitry A. Kazakov wrote:

On Sat, 5 Mar 2005 17:52:36 +0000 (UTC), Martin Dowie wrote:

... Joe Bloggs, who taught himself (badly) at home ...

I don't think that he would be the worst possible choice. Look, if somebody
has a desire to be taught (+5 points), and is ready to do it by himself
(+20!), at his spare time at home (+100!). That's far above the average. I
saw much worse cases!

I did say this hypothetical self-taught person taught themselves
'badly'! :-)

Cheers

-- Martin

[Ludovic Brenta]

Peter Koch Larsen writes:

"Ludovic Brenta" skrev i en meddelelse

procedure Proc (A : in String) is
begin
for J in A'Range loop
J := J + 4; -- illegal, J is constant inside the loop
end loop;
Do_Womething_Wi th (J); -- illegal, J no longer exists
end Proc;
This is inherited from Pascal if I remember correctly. Of course,
good C++ style is to declare your variable in the loop.

Most of Ada's syntax is inherited from Pascal. In fact, Ada is
"Pascal done right", since Ada eliminated most of Pascal's problems
like separate compilation or the infamous "dangling else" problem. For
that matter, these problems also exist in C and C++.

It is true that, in ISO C++, loop variables declared in the for
statement are not visible outside the loop. However, the library I
was working on did make use of the loop variable after the loop, and
none of our 4 or 5 different C++ compilers complained about it.

Which brings me to the general question: is there any
standard-compliant C++ compiler in existence? Or are compilers only
"mostly compliant" or "close enough" or some other ill-defined term?

By contrast, consider Ada's formal validation process, which is also
an ISO standard (ISO/IEC 18009 - Ada: Conformity assessment of a
language processor). In the 1980's, the DoD held the trademark "Ada",
and only validated compilers were allowed to call themselves "Ada
compilers". Now, the rules are more lax, but all compilers in
existence pass the validation suite. See:

http://www.ada-auth.org/acats.html

* conditions cannot mix "and" and "or" without parentheses. Thus
there is no possibility that the programmer make wrong assumptions
about precedence of operators or order of evaluation.

This seems ridiculous. I would expect a programmer to know the
precedence rules or at least insert parentheses if they are in
doubt.

This is the crux of the problem. Assuming that the programmer "knows
the rules", "makes no mistakes" or "can be trusted" is a recipe for
disaster. One of the principles in Ada's rationale is to make
everything explicit, rather than implicit.

* the type system, when used appropriately, makes it possible for
the compiler to find semantic errors in addition to just syntax
errors. For example, you can declare that Numers_Of_Apple s and
Numers_Of_Orang es cannot be mixed. This is not possible with C++'s
typedef.

I like that idea. It is possible using templates, of course. Is it
general enough? If you replace "apples" with "weight" and "oranges"
with "length", is it then permissible to multiply a length with a
weight but not add the two together?

Yes:

type Weight is digits 8 range 0.0 .. 900.0; -- 8 decimal digits of precision
type Length is digits 8 range 0.0 .. 1000.0;

Now these types are incompatible. If you want to mix them, you need
to define the semantics and provide the appropriate operators:

type Weight_Length is digits 8 range 0.0 .. 900_000.0;

function "*" (Left : in Weight; Right : in Length) return Weight_Length;

Since you don't provide "+", there is no way to add a weight to a
length.

For a more general discussion of physical quantities in Ada, see:

http://home.t-online.de/home/Christ-.../Universe.html

* conversions from floating point to integer types involve
rounding. The rounding is precisely and deterministical ly defined
by the ISO standard for the Ada language. Similarly,
floating-point and fixed-point types can be declared with known,
deterministic, guaranteed precision.

This point sounds as if it restricts the environments where Ada can
be used.

Do you mean that not all targets may implement the requested
precision? That is true but it is not a language issue. Ada
compilers are required to document which precision they support for
their targets.

And fixed-point types being really nothing more than integers, all
targets support them to some extent.
I sort of like this one as well - although raising an exception
seems to be to forgiving.
What other mechanism would you suggest?
My conclusion is that there are some nice ideas out there, but that
they mainly protect against the "sloppy" programmer.

It is a mistake to assume that the programmer makes no mistakes.
Mistakes are a given fact of the human nature. Ada is designed with
this in mind.

A sloppy programmer will avoid Ada like the plague, because they
resent discipline in general and don't appreciate being taught
lessons. A good software engineer will be attracted to Ada because
she is a powerful ally.

--
Ludovic Brenta.

[Larry Kilgallen]

In article <11************ **********@g14g 2000cwa.googleg roups.com>, "EventHelix.com " <ev********@gma il.com> writes:

What specific features are you missing in C++. Before moving
to Ada consider this:

- It will be hard to find developers for Ada
To hire developers who are incapable of learning a second language
is really scraping the bottom of the barrel. If that were the case,
I would hope the product is not one on which I will ever depend.
- You might end up making more mistakes with Ada because of
inexperience with Ada.

But if you do, they will typically be caught at compile-time.