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?

[Ioannis Vranos]

Ludovic Brenta wrote:

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.

With Ada aside (I find no reason why one should not learn it), C++ is a
powerful and systems programming language, and power implies painful low
level details. However it also provides all major high level facilities,
and if you stick in high level programming it is very safe, while it
maintains the maximum space and run-time efficiency principle.
For example consider using std::string for strings, std::vector for
arrays etc.
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;

Yes but this limits flexibility.

Also notice that, in Ada, the "for" statement declares the loop
variable automatically.

That's not a big deal.

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.

It looks like the code was not ISO C++ compliant.


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.

* 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.

* 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.

* pointer types cannot be converted to one another. You cannot
convert a pointer-to-String to a pointer-to-random-object.

* 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.

* 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.

In general, we cannot compare the two languages because they have
different design ideals.
C++ supports 4 paradigms. Each paradigm is supported well with maximum
run-time/space *efficiency*. At the same time it leaves no room for a
lower level language except of assembly.
On the other hand I do not know ADAs ideals (for example I do not think
it supports the generic programming paradigm - templates), but I suspect
they are to be an easy (restricted to easy parts), safe (not letting you
do low level operations), application development language, which is OK
for usual application development.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Larry Kilgallen]

In article <3S************ *********@news0 00.worldonline. dk>, "Peter Koch Larsen" <pk*****@mailme .dk> writes:

- You might end up making more mistakes with Ada because of
inexperience with Ada.

Wrong. I took that route 4 years ago, and found that the compiler
would catch all my stupid mistakes. When it comes to reliability, Ada
compilers are your friends; C++ compilers are your enemies.

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.

Which C++ compilers prevent those practices deprecated in your second
sentence ?

[Mark Lorenzen]

Ioannis Vranos <iv*@remove.thi s.grad.com> writes:

[snip]

On the other hand I do not know ADAs ideals (for example I do not
think it supports the generic programming paradigm - templates), but I
suspect they are to be an easy (restricted to easy parts), safe (not
letting you do low level operations), application development
language, which is OK for usual application development.

First of all, the language is called Ada. It is not an acronym, but a
woman's name.

Ada supports generic ("template") programming very well. It
furthermore lets you do all the low-level operations you can think of:
Reading from a memory location, converting bit sequences into
integers, performing pointer arithmetic etc. You can f.x. convert an
octet into an array of Booleans and thus refer to each "bit" as a
Boolean value.

Give it a try - it never hurts to gain experience with new/other
programming languages. The people at comp.lang.ada are always willing
to help and answer questions.

Regards,
- Mark Lorenzen

[Larry Kilgallen]

In article <y8************ *********@news0 00.worldonline. dk>, "Peter Koch Larsen" <pk*****@mailme .dk> writes:

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

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: This is inherited from Pascal if I remember correctly. Of course, good C++
style is to declare your variable in the loop.
That is also good style in macro assemblers, and presumably in paper-only
languages used to write machine code where you toggle in the binary. But
the purpose of a compiler is to help you avoid errors, whether you think
of such things at the time or not.
* 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.

Expectations are one thing, but having the compiler help you is better.

* 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?

It is possible, with enough work, to do such things.

It is preferable to mandate that such project-specific needs be
programmed only by senior programming staff. Thus the junior
members of the staff just say this_box_length * this_box_weight .

Any responsibility for the meaningfulness of that result is on the
shoulders of senior staff.
My conclusion is that there are some nice ideas out there, but that they
mainly protect against the "sloppy" programmer.

My conclusion after 35 years with computers is that there are "sloppy"
programmers out there. So I look for mechanisms to guard against such
things. Formal inspection is great, but it is a waste of resources if
used to catch small errors that can be avoided with proper choice of
tools.

[Ludovic Brenta]

Ioannis Vranos writes:

In general, we cannot compare the two languages because they have
different design ideals.
C++ supports 4 paradigms. Each paradigm is supported well with
maximum run-time/space *efficiency*. At the same time it leaves no
room for a lower level language except of assembly.
Ada's efficiency is on par with C++'s, thank you very much. In fact,
the most widely used Ada compiler is none other than GCC.
On the other hand I do not know ADAs ideals (for example I do not
think it supports the generic programming paradigm - templates),
Ada can teach C++ how to do templates properly. In Ada they are
called "generics". The reason why Ada's generics are better (IMHO)
than C++'s templates is that Ada alows you to express constraints
between generic parameters. There is also a rich set of possible
generic parameters. A generic parameter can be a type, an object, a
subprogram, or a package (in which case the actual package must be an
instance of some designated generic package!). For example, in Ada,
you can say that a generic takes a type parameter which must be a
subclass of some designated class. You can then go on to say that a
second parameter must be an instance of that particular subclass.

Ada supports procedural programming, object-oriented programming,
genericity, and exceptions, just like C++.

And, Ada supports multitasking. How's that for a multiparadigm
language?

The one thing that C++ supports that Ada doesn't is multiple
inheritance. This feature was left out as unsafe. Interface
inheritance Ã* la Java is being added in Ada 2005.
but I suspect they are to be an easy (restricted to easy parts),
safe (not letting you do low level operations), application
development language, which is OK for usual application development.

Ada also has low-level facilities for systems programming. These
facilities allow doing bit-level programming *cleanly* and
*explicitly*. An entire chapter of the Ada reference manual is
devoted to this - chapter 13, "representa tion issues".

This means that, uness you see a representation clause or uses of
Unchecked_Conve rsion or Unchecked_Deall ocation, you can pretty much
assume that an Ada program uses only safe features. In Ada, unsafe
programming is possible but must be explicit.

There is also a gem of a language feature: pragma Restrictions. This
pragma allows you to restrict usage of some language features, *and
the compiler enforces the restrictions*. But the possible
restrictions are implementation-defined.

--
Ludovic Brenta.

[Ioannis Vranos]

Martin Krischik wrote:

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;

Day_Of_Month does not compile. You can make the Day_Of_Month an enum:
enum Day_Of_Month { Mon=1, Sun=7};
int main()
{
Day_Of_Month X= 32;
}
C:\c>g++ temp.cpp -o temp.exe
temp.cpp: In function `int main()':
temp.cpp:6: error: invalid conversion from `int' to `Day_Of_Month'

C:\c>

The char Y thing does not compile, but try this:

#include <vector>

int main()
{
using namespace std;

vector<char> Y (10);

Y.at(10) = 'X';
}
The most important thing that you may be missing, is that in C++ you can
choose the level of abstraction and safety you want by using some
third-party library or framework that fits your needs.
For example consider this:
// Using .NET facilities
int main()
{
using namespace System;

array<int> ^IntArray= {1,2,3,4,5,6,7, 8,9,0};

IntArray[10]= 10;
}
C:\c>temp

Unhandled Exception: System.IndexOut OfRangeExceptio n: Index was outside
the boun
ds of the array.
at main()

C:\c>

#include <iostream>
#include <ostream>

int main()
{
using namespace System;
using namespace std;

int x= 71;

char c= x.ToString()[0];

cout<<c<<endl;

cout<<x.ToStrin g()->Length<<endl ;
}

C:\c>temp
7
2

C:\c>
The above make use of the .NET 2 framework facilities, which provide
additional safety and the high level things you are mentioning.
Bottom line is in C++ you can be as safe and as high level you like.
Just pick the suitable libraries or frameworks.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Mark Lorenzen wrote:

You can do everything in Ada that you can in C and C++.

I suppose you mean in the application-programming domain. But I do not
think this is true in the systems programming domain, that is efficiency
under *severe* run-time and space constraints.
Also I am not sure if ADA is suitable for library writing, or you will
have to switch to another language to do that.

I do not say this is bad, since the design ideals of ADA are different
from C++. In effect, we are comparing different things here.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ludovic Brenta]

Ioannis Vranos writes:

Bottom line is in C++ you can be as safe and as high level you
like. Just pick the suitable libraries or frameworks.

No, you cannot be as safe as you like. For this, you would need the
ability to restrict usage of unsafe features. Just because you also
have safe features at your disposal does not force you to use them.

Your sentence should read: in C++, despite all the high-level
features, you can be as unsafe as you like because the compiler will
let you.

--
Ludovic Brenta.

[Mark Lorenzen]

Ioannis Vranos <iv*@remove.thi s.grad.com> writes:

Mark Lorenzen wrote:

You can do everything in Ada that you can in C and C++.

I suppose you mean in the application-programming domain. But I do not
think this is true in the systems programming domain, that is
efficiency under *severe* run-time and space constraints.

Why? I see no reason that an executable programmed in Ada should be a
slow or big?


Also I am not sure if ADA is suitable for library writing, or you will
have to switch to another language to do that.

Why?

Regards,
- Mark Lorenzen

[xpyttl]

"Larry Kilgallen" <Ki*******@Spam Cop.net> wrote in message
news:tx******** **@eisner.encom passerve.org...

- 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.

I would argue that this isn't strictly true. Of course, the bonehead errors
will be caught by the compiler, but the same is true for C++.

I found that, while I could write servicible code pretty quickly in Ada, it
took a long time, coming from C (and Pascal before that), to really
understand how to exploit the language.

By way of example, someone in this thread posted an example using a
Day_of_Month type. It would never occur to a C programmer that the day of
the month was anything other than an integer. At the other extreme, once
discovering all this wonderful capability, it is very easy to get carried
away and take it to extremes. It takes quite some experience to understand
the correct balance for just this one useful feature of the language.

I also feel that Ada programs are more difficult -for experienced
programmers- to read. Sure, any Joe off the street can probably get more
from an Ada program than a C++ program, but C and C++ have a lot of idioms
that express fairly large concepts in immediately recognizable ways. With
Ada, not only is there less of this, but the language is so wordy that even
simple functions seem to go on and on.

Still, if I was back doing safety critical code, I don't think I could
honestly argue that C++ was a viable choice.

...