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

  • Thread starter Turamnvia Suouriviaskimatta
  • Start date
T

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

Ludovic Brenta

Turamnvia Suouriviaskimatta said:
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?

Your knowledge of Delphi will help a great deal, more than your
knowledge of C++. Learning a new imperative language is not all that
difficult once you know a couple other imperative languages.

I suggest you browse http://www.adaic.org, it has several books and
tutorials on-line, as well as references of hardcopy books you can
buy. You may be interested in "Ada Distilled" by Richard Riehle.
Here is a direct link to it:

http://www.adaic.org/docs/distilled/adadistilled.pdf
 
E

EventHelix.com

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

- It will be hard to find developers for Ada
- You might end up making more mistakes with Ada because of
inexperience with Ada.
- Ada tools will fall short of the extensive set of C++ related tools.

Deepa
 
L

Ludovic Brenta

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

- It will be hard to find developers for Ada

Wrong. There are more and more people knowledgeable in Ada, and if
someone won't learn, they probably are not a good software engineer to
begin with. The OP, at least, shows proper scientific attitude of
willingness to learn and of choosing based on facts, not perception.
- 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.
- Ada tools will fall short of the extensive set of C++ related tools.

This depends on the actual environment; such a broad statement, not
backed up by any hard evidence, is just plain FUD.
 
D

Dmitry A. Kazakov

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?

I don't think it is difficult. I learned C after Ada [83], that was
difficult! If you know C++ you will find the concepts of classes and
templates in Ada again, however, built on a different fundament. From
Delphi you'll find a close, but much improved syntax, packages instead of
units. OO/ADT in Ada is closer to C++ than to that stump in Delphi. If you
programmed multi-threaded applications in C++, you will enjoy Ada's tasks
and protected objects.
What is the best way of learning Ada for a C/C++ programmer?

As with any language, the best way is to buy a pile of books, but not
before starting a project. Do not concentrate on implementation details,
avoid micro optimization (common to C programmers), enjoy "renames" instead
of T& or Delphi's "with", never use pointers and remember, array index
starts where you want it do! :)-))
 
P

Peter Koch Larsen

Ludovic Brenta said:
EventHelix.com said:
What specific features are you missing in C++. Before moving
to Ada consider this:

[snip]
- 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.

Kind regards
Peter

[snip]
 
M

Matthias Kaeppler

Turamnvia said:
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?

It hasn't a lot in common with C-based languages. Its origin is in
Pascal and Algol. I had to wite an article about Ada just recently while
I had never worked with it before. I didn't find it too hard to get into
it, but I don't consier myself "knowing" Ada well, either (only worked a
couple of weeks with it).
I didn't like the OO facilities, it feels like OO was stomped into the
language just to keep up with modern OO languages (actually, that's
exactly what happened with Ada-95).
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).

Ada has a very interesting type system, which e.g. allows you to define
your own fundamental types, e.g. fixed point types (you can even define
how many digits it may have etc). Ada also has generics, but is
primarily based on data abstraction in terms of data structures (called
'records' in Ada).

Overall I'd say your C++ knowledge is pretty useless when you learn Ada,
but a general, fundamental experience with computer programming is
always good enough to get into a new language relatively quick IMO.
 
J

Jeff C

Turamnvia said:
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?

This short tutorial appears to work quite well for C/C++ programmers I
have used on my projects.

www dot adahome dot com/Ammo/cpp2ada.html

Note that everything at adahome is old and out of date since this
website stopped updating many years ago. The front page of the website
pretends to update every day by updating a date field so it tends to
rank high on search engines (so I try to avoid linking to the website on
a personal crusade to lower its rankings).

www.adapower.com
www.adaworld.com

are to good jumping off points that are maintained.

I still point to that tutorial for new staff though because for talented
engineers it brings them up to speed very quickly.

I have been working with Ada on real projects for many years now.
(genererally Embedded, real-time, distributed processing mid sizes
projects of about 100K SLOC).

During that time I have had lots of different engineers come on and off
projects. A few of them knew Ada. Most did not. In general, any (stated)
a priori knowledge of Ada was not at all a good predictor of their
usefulness to the projects.

Talented engineers are productive in any environment where the tools are
not garbage and the requirements are at least somewhat better than
mud. Bad engineers write bad code in any language. This is true even
after many years of being "professional" programmers.

(For some fun read these two papers:
http://www.paulgraham.com/gh.html
http://www.paulgraham.com/pypar.html)


Switching to a language where no one on the project has any experience
IS however a risk. You can search through the literature and find plenty
of examples of projects that failed (at least partly, and based on my
previous comment perhaps not as much as the engineers would like to
believe) because they were not familiar with the language (e.g. C++,
Java, Ada) they selected.

Whatever language you choose you should attempt have a champion or two
on the project that has worked with it before. Perferably these people
would actually be good at the language AND software design/architecture
in general. Identifying these good engineers up front is left as an
exercise for the reader.

Realize that no language is a magic bullet that "solves" all problems.


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

Ludovic Brenta

Peter said:
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.

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_With (J); -- illegal, J no longer exists
end Proc;

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.

* 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_Apples and
Numers_Of_Oranges 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 deterministically 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.
 
M

Mark Lorenzen

Peter Koch Larsen said:
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.

It serves no purpose to find small (theoretic) examples where f.x. Ada
will be an advantage over C++. These examples will always be
repudiated in long discussions. In order to appreciate one language
over another, you need to have used it in a "real" system of a certain
size.

I have used both C++ and Ada in large projects and (until now) I
prefer Ada over C++ (yes, the modern usage with STL, function objects
and templates). Ada gives me better productivity, fewer errors and
(most of all) a sense of engineering instead of programming.

But you of course need to learn a language in order to judge it, so
just programming small examples where you maybe touch 25% of the
languages doesn't really give the language any credit. And that is the
catch with using "new" languages in a commercial environment: There is
no time to learn a new language and therefore no time to evaluate
alternatives.

Regards,
- Mark Lorenzen
 
M

Mark Lorenzen

[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
 
P

Peter Koch Larsen

Ludovic Brenta said:
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_With (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_Apples and
Numers_Of_Oranges 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 deterministically 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.

Thanks for your answer
Peter
 
M

Martin Krischik

He Peter,

Peterath said:
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
 
P

Pascal Obry

EventHelix.com said:
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
 
M

Martin Dowie

Peter said:
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
 
E

Ed Falis

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
 
D

Dmitry A. Kazakov

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

Martin Dowie

Dmitry said:
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
 
L

Ludovic Brenta

Peter said:
"Ludovic Brenta" skrev i en meddelelse

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
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.
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-Usch.Grein/Ada/Universe.html
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.
 
I

Ioannis Vranos

Ludovic said:
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_With (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_Apples and
Numers_Of_Oranges 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 deterministically 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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,832
Latest member
GlennSmall

Latest Threads

Top