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?

[Ludovic Brenta]

"Turamnvia Suouriviaskimatta" <TS> writes:

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

--
Ludovic Brenta.

[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
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Real-time and Embedded System Modeling with Sequence Diagrams

[Ludovic Brenta]

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

--
Ludovic Brenta.

[Dmitry A. Kazakov]

On Sun, 6 Mar 2005 00:42:05 +1100, Turamnvia Suouriviaskimatta wrote:

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! (:-))

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

[Peter Koch Larsen]

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

"EventHelix.com" writes:

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]

--
Ludovic Brenta.

[Matthias Kaeppler]

Turamnvia Suouriviaskimatta wrote:

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.

--
Matthias Kaeppler

[Jeff C]

Turamnvia Suouriviaskimatta wrote:

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.

[Ludovic Brenta]

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.

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.

--
Ludovic Brenta.

[Mark Lorenzen]

"Peter Koch Larsen" <pk*****@mailme.dk> 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.

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

[Mark Lorenzen]

Matthias Kaeppler <no****@digitalraid.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.org...

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

--
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********@gmail.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.com> 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_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.

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

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

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.

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

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Larry Kilgallen]

In article <11**********************@g14g2000cwa.googlegroups .com>, "EventHelix.com" <ev********@gmail.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.

[Larry Kilgallen]

In article <3S*********************@news000.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.this.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*********************@news000.worldonline.dk> , "Peter Koch Larsen" <pk*****@mailme.dk> writes:

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

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

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, "representation issues".

This means that, uness you see a representation clause or uses of
Unchecked_Conversion or Unchecked_Deallocation, 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.IndexOutOfRangeException: 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.ToString()->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.this.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*******@SpamCop.net> wrote in message
news:tx**********@eisner.encompasserve.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.

...

[Ludovic Brenta]

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

Then why is it that almost all spacecraft, satellites, airplanes,
trains, nuclear power stations, submarines are programmed in Ada? Is
that not real-time enough for you? Remember the Mars rover? Ada.
The Cassini-Huygens mission? Ada. Europe's air traffic control
network? Ada. The US air traffic control network? Ada.

I myself am involved in writing system-level avionics software. There
is no operating system. We do address and data manipulations at the
bit level. We write to processor registers. There are hard real-time
constraints, as well as safety constraints. We write all of this in
Ada, with a few machine code insertions ("inline assembler") in a
couple places.

I have a feeling that you just don't know what you are talking about.
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 will repeat what Mark Lorenzen just said above:

You can do everything in Ada that you can in C and C++.
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.

Yes, we are comparing a hacker's language with an engineer's language.

--
Ludovic Brenta.

[Ioannis Vranos]

Ludovic Brenta wrote:

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?

int main()
{
for(int i=0; i<10; ++i)
;

i=7;
}

C:\c>g++ temp.cpp -o temp.exe
temp.cpp: In function `int main()':
temp.cpp:6: error: name lookup of `i' changed for new ISO `for' scoping
temp.cpp:3: error: using obsolete binding at `i'

C:\c>

C:\c>cl temp.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.41013 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

temp.cpp
temp.cpp(6) : error C2065: 'i' : undeclared identifier

C:\c>

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ludovic Brenta wrote:

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.

You can also express constraints in templates. An important thing is
this. Are Ada's generics run-time or compile time?

As I said in another message of mine, in C++ you can "plug in" whatever
you want by using third-party libraries and frameworks.
For example in .NET 2, C++ will have both its compile-time templates and
..NET's 2 run-time generics (with the keyword generic).

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

It looks like they are run-time, and in C++ you can do all the above.
Actually Ada's compilers are probably written in C++.
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?

I suppose you mean multithreading. You can do that in C++ in many
different ways, by "plugging in" the necessary facilities:
By using the OpenMP standard (http://www.openmp.org)

#include <vector>

int main()
{
using namespace std;

vector<int> somearray(10);

#pragma omp for
for(vector<int>::size_type i=0; i<somearray.size(); ++i)
somearray[i]=i;
}
The above pragma tells the compiler that each operation on vector's
elements is independent from the others, and thus the compiler instantly
creates a thread for each assignment, taking advantage of any
multiprocessor/multicore CPUs that exist.

Unknown #pragmas are ignored by compilers, so a compiler not supporting
OpenMP still compiles the code.
In .NET you can also use its multithreading facilities, in addition to
OpenMP:
// .NET multithreading thread-lock model
__gc class SomeClass
{
int index;

//...

public:

// ...
void DoSomething()
{
Monitor::Enter(this);

// Modify index

Monitor::Exit();
}

void DoSomethingElse()
{
Monitor::Enter(this);

// Modify index

Monitor::Exit();
}

// ...
};
SomeClass *ps= __gc new SomeClass;

// ...

Thread *pthread1= __gc new Thread ( __gc new ThreadStart(ps,
&SomeClass::DoSomething) );

Thread *pthread2= __gc new Thread ( __gc new ThreadStart(ps,
&SomeClass::DoSomethingElse) );
//Start execution of ps->DoSomething()
pthread1->Start();

//Start execution of ps->DoSomethingElse()
pthread2->Start();

// ...
The are innumerable ways that you can do things in C++, you just 'plug
in" the additional facilities that you want.
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, "representation issues".

Do you know std::bitset?


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

In C++ you can be as safe, restricted and convenient as you want.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

In C++ you can be as safe, restricted and convenient as you want.

Including garbage collection.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Simon Wright]

Ludovic Brenta <lu************@insalien.org> writes:

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

It is extremely easy to make dangling pointers.

Ada makes it hard to have pointers to objects whose _type_ has gone
out of scope, but that's fairly unusual!

--
Simon Wright 100% Ada, no bugs.

[Adrien Plisson]

Ludovic Brenta wrote:

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.

there is also one other thing i can think of: template specialization.

this is an interresting construct, used a lot in C++, which gives the
ability to write "traits". there may be a way to do it in Ada but i'm
not aware of it (if there is, please tell me).

--
rien

[Pascal Obry]

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

It looks like they are run-time, and in C++ you can do all the
above. Actually Ada's compilers are probably written in C++.

At least GNAT (GNU/Ada) is written in Ada and DEC Ada was written in Ada IIRC.

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

[Paul E. Bennett]

Ludovic Brenta wrote:

Then why is it that almost all spacecraft, satellites, airplanes,
trains, nuclear power stations, submarines are programmed in Ada? Is
that not real-time enough for you? Remember the Mars rover? Ada.
The Cassini-Huygens mission? Ada. Europe's air traffic control
network? Ada. The US air traffic control network? Ada.
You wrote that like Ada was 100% of the software content of those missions.
Far from it. Cassini also used some Forth on board (see list at:-
<http://forth.gsfc.nasa.gov/>). I am sure that wasn't the only alternative
language used either.

[%X]
Yes, we are comparing a hacker's language with an engineer's language.

I am sure that hackers can work in many languages, even Ada. Engineering is
a process thing not T&E.

--
************************************************** ******************
Paul E. Bennett ....................<email://pe*@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: [phone]
Tel: [phone]
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
************************************************** ******************

[Pascal Obry]

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

int main()
{
for(int i=0; i<10; ++i)
;

i=7;
}

And what about:

int main()
{
int i;
for(i=0; i<10; ++i)
;

i=7;
}

What is important for safety is not what a language permits but what
it forbids. As long as you have traps in a language you know that some
programmers will fall into it at some point.

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

[Dennis Lee Bieber]

Ugh... Cross-posted.... And since I don't know which group
replies are being /read/ from...

On Sat, 5 Mar 2005 17:30:23 +0100, "Peter Koch Larsen"
<pk*****@mailme.dk> declaimed the following in comp.lang.ada:

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?
Only if you've defined an overloaded "*" operator (and you also
have to overload for each order of arguments).

In the case of the apples/oranges, one could also create a
"FruitBasket" type, then overload

function "+"(left:apples; right:oranges) return FruitBasket
and
function "+"(left:oranges; right:apples) return FruitBasket

You would, inside of these overloads, have to "convert" apples
and oranges to base numeric types, do the addition on that, then
"convert" the result to FruitBasket.

For your length and weight, add a torque type, and define the
proper operator

function "*"(left:length; right:weight) return torque

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

[Adrien Plisson]

Ioannis Vranos wrote:

For example in .NET 2, C++ will have both its compile-time templates and
..NET's 2 run-time generics (with the keyword generic). #include <vector>

int main()
{
using namespace std;

vector<int> somearray(10);

#pragma omp for
for(vector<int>::size_type i=0; i<somearray.size(); ++i)
somearray[i]=i;
}
your 2 examples seems not standard C++. i don't think my favorite C++
compiler will understand "#pragma omp ..." out of the box, nor even
"generic".
In .NET you can also use its multithreading facilities, in addition to
OpenMP: [snipped a long example of multi-threaded things relying on functions
which are not in the C++ standard]

if you had ever written any multi-threaded code in Ada, you would have
been ashamed of the example you gave.

protected Index is
procedure Set( I : Integer );
function Get return Integer;
end Index;

task Do_Something is
begin
-- use Index as you wish
end Do_Something;

task Do_Something_Else is
begin
-- use Index as you wish
end Do_Something_Else;

(the above example, does the same as your C++ example)
The are innumerable ways that you can do things in C++, you just 'plug
in" the additional facilities that you want.
additional facilities you are talking about are called "third party
libraries". any language have some, including C++ and Ada.
Do you know std::bitset?

IIRC, std::bitset is implemented in term of functions performing at
runtime the shift operations required to access a single bit.

--
rien

[Adrien Plisson]

i just forgot some implementation details in my example. here is the
complete example:

protected Index is
procedure Set( I : Integer );
function Get return Integer;
private
Value : Integer;
end Index;

protected body Index is
procedure Set( I : Integer ) is
begin
Value := I;
end Set;

function Get return Integer is
begin
return Value;
end Get;
end Index;

task Do_Something;
task Do_Something_Else;

task body Do_Something is
begin
-- use Index as you wish
end Do_Something;

task body Do_Something_Else is
begin
-- use Index as you wish
end Do_Something_Else;

--
rien

[Ioannis Vranos]

Pascal Obry wrote:

And what about:

int main()
{
int i;
for(i=0; i<10; ++i)
;

i=7;
}

What is important for safety is not what a language permits but what
it forbids. As long as you have traps in a language you know that some
programmers will fall into it at some point.

Every variable is visible inside the scope that it was defined.

If you want to use i inside a for loop only, then define it in the for loop.
The restriction that you imply you desire, limits flexibility.

Once again, I have nothing against learning Ada, however personally I
like the most powerful languages. The next thing I am going to learn
after C++ (because I haven't learned it all yet), is probably some form
of assembly language.
For example I like that I can do:

#include <iostream>
#include <string>
#include <bitset>
#include <limits>

class SomeClass
{
std::string s;

public:
SomeClass()
{
s="This is a text message";
}
};
int main()
{
using namespace std;

SomeClass obj;

unsigned char *p= reinterpret_cast<unsigned char *>(&obj);

// Displays the individual bytes that obj
// consists of as unsigned chars.
for(unsigned i=0; i<sizeof(obj); ++i)
cout<<"character: "<<p[i]<<"\n";

cout<<"\n";
p= reinterpret_cast<unsigned char *>(&obj);
// Displays the decimal values of the
// individual bytes that obj consists of.
for(unsigned i=0; i<sizeof(obj); ++i)
cout<<static_cast<unsigned>(p[i])<<" ";

cout<<"\n\n";
// Displays the bits of each byte that consist
// this SomeClass object
p= reinterpret_cast<unsigned char *>(&obj);
for(unsigned i=0; i<sizeof(obj); ++i)
{
// A byte is not necessarily 8 bits
// numeric_limits<unsigned char>::digits retrieves the number
// of byte's bits, which *is* 8 usually.
bitset<numeric_limits<unsigned char>::digits> bits(p[i]);

for(unsigned j=0; j<bits.size(); ++j)
cout<<bits[j];

cout<<"\n";
}
}
C:\c>temp
character: �
character: =
character: >
character:

252 61 62 0

00111111
10111100
01111100
00000000

C:\c>
I am sure that many ADA developers will say that this one is not needed
(the ability to access the individual bytes of objects is needed in many
cases, e.g. to create low level exact copies of objects ) and it is
unsafe (yes it is, low level stuff are unsafe and it all depend on the
programmer knowing what he does).
It is up to oneself to learn whatever languages fits his purposes. For
example, a "safe" language is not an interest for me.

Someone who places much hopes on the language to protect him from his
mistakes, probably ADA is better than C++ on this.
There is no language that provides satisfies all people desires, just
because some desires are in contrast between them.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Larry Kilgallen]

In article <1110052142.832650@athnrd02>, Ioannis Vranos <iv*@remove.this.grad.com> writes:

Ludovic Brenta wrote:

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.

In that case, it looks like the compiler failed to detect that shortcoming.

[Paul E. Bennett]

Ludovic Brenta wrote:

* 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 think the fallacy of that statement has been proven already (in a very
expensive way).
--
************************************************** ******************
Paul E. Bennett ....................<email://pe*@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: [phone]
Tel: [phone]
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
************************************************** ******************

[Larry Kilgallen]

In article <1110053977.478846@athnrd02>, Ioannis Vranos <iv*@remove.this.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.

And what guesswork makes you think there would be efficiency problems
with Ada ?
Also I am not sure if ADA is suitable for library writing, or you will
have to switch to another language to do that.

Huh ?

Again, what guesswork makes you suggest that ?

It is even possible in Ada to make the calling convention be the
unsafe C-style interface (null terminated strings, etc.). But for
better safety in all the languages that might call the library,
it is better to avoid those C conventions.

[Ioannis Vranos]

Ioannis Vranos wrote:

C:\c>temp
character: �
character: =
character: >
character:

252 61 62 0

00111111
10111100
01111100
00000000

C:\c>

Keep in mind that the code displays how things are implemented by the
specific compiler. For VC++ 2005 Express Beta 1 we get:
C:\c>cl /EHsc temp.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.41013 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

temp.cpp
Microsoft (R) Incremental Linker Version 8.00.41013
Copyright (C) Microsoft Corporation. All rights reserved.

/out:temp.exe
temp.obj

C:\c>temp
character: ♂
character: Ψ
character: A
character:
character: Ι
character: /
character: 3
character:
character: α
character:
character: B
character:
character: â–‘
character:
character: ↕
character:
character: <
character: â•¡
character: @
character:
character: â–¬
character:
character:
character:
character: â–¼
character:
character:
character:

11 150 65 0 136 47 51 0 152 8 66 0 176 255 18 0 60 181 64 0 22 0 0 0 31
0 0 0

11010000
01101001
10000010
00000000
00010001
11110100
11001100
00000000
00011001
00010000
01000010
00000000
00001101
11111111
01001000
00000000
00111100
10101101
00000010
00000000
01101000
00000000
00000000
00000000
11111000
00000000
00000000
00000000

C:\c>
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Peter Koch Larsen]

"Larry Kilgallen" <Ki*******@SpamCop.net> skrev i en meddelelse
news:zr**********@eisner.encompasserve.org...

In article <3S*********************@news000.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 ?

It is not a question of prevention. C++ allows you to do some really
dangerous things - in my mind rightfully so. When you do program in C++ you
must "constrain yourself" and not use the dangeous stuff - unless you need
to do so, of course ;-)
It's kind of like driving. You can get into a lot of trouble if you do not
follow the traffic laws (you just have to obey the physicla ones ;-), but so
long as you do driving is a fairly safe practice.

/Peter

[Peter Koch Larsen]

"Larry Kilgallen" <Ki*******@SpamCop.net> skrev i en meddelelse
news:Q5**********@eisner.encompasserve.org...

In article <1110053977.478846@athnrd02>, Ioannis Vranos
<iv*@remove.this.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.

And what guesswork makes you think there would be efficiency problems
with Ada ?

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

Huh ?

Again, what guesswork makes you suggest that ?

It is even possible in Ada to make the calling convention be the
unsafe C-style interface (null terminated strings, etc.). But for
better safety in all the languages that might call the library,
it is better to avoid those C conventions.

It is also possible to use zero-terminated strings in C++, but every
knowledgeable person will advice that you use std::string. So what is the
difference here?

/Peter

[Ioannis Vranos]

Ioannis Vranos wrote:

and it is
unsafe (yes it is, low level stuff are unsafe and it all depend on the
programmer knowing what he does).

But it *is* portable.

--
Ioannis Vranos

http://www23.brinkster.com/noicys