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

[Turamnvia Suouriviaskimatta]

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

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

"Ioannis Vranos" <iv*@remove.thi s.grad.com> wrote in message
news:1110645475 .497596@athnrd0 2...

There are compliance tests for C++ too.

True. However, I have never known a single DoD contractor
to require a validated C++ compiler. I have never heard of
a single DoD program manager who rquired a validated C++
compiler. If anyone did demand this level of rigor, there would
be far less C++ used by DoD contractors, but there might also
be some improvement, ultimately, in C++ compilers.

If someone chooses Ada for a military project, one of the first
questions from the program manager is, "Is the compiler validated?"
Ada is almost always held to a higher standard that we other
languages - and this is as it should be.

Still, when we hold one development environment (an Ada compiler)
to a higher standard, we need to understand that difference when
making comparions. It costs a great deal more money to produce
a compiler that must pass validation (now conformity) than to
create one in which the defects are intended to be discovered
by the users and fixed in some future release.

Richard Riehle

"Robert A Duff" <bo*****@shell0 1.TheWorld.com> wrote in message
news:wc******** *****@shell01.T heWorld.com...

...but of course there's a lot of market pressure to produce
standard-conforming compilers, for those languages that have official
standards (Ada, C, C++, Fortran, Cobol, etc).

Not Eiffel?

Richard Riehle

[Jerry Coffin]

ad******@sbcglo bal.net wrote:

"Robert A Duff" <bo*****@shell0 1.TheWorld.com> wrote in message
news:wc******** *****@shell01.T heWorld.com...

...but of course there's a lot of market pressure to produce
standard-conforming compilers, for those languages that have
official standards (Ada, C, C++, Fortran, Cobol, etc).

Not Eiffel?

TTBOMK, Eiffel doesn't have an official standard. If there was an ISO
standard, it would naturally fall under JTC1/SC22, but the ISO
JTC1/SC22 web site: http://www.open-std.org/jtc1/sc22/, doesn't mention
Eiffel anywhere.

Searching for Eiffel on the ANSI, ECMA and IEEE web sites fails to turn
up anything positive either -- ANSI and ECMA come up completely dry and
while IEEE cites a number of papers on Eiffel, none that I could find
looked like an official standard.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Yermat]

Jerry Coffin wrote:

ad******@sbcglo bal.net wrote:

"Robert A Duff" <bo*****@shell0 1.TheWorld.com> wrote in message
news:wc****** *******@shell01 .TheWorld.com.. .

...but of course there's a lot of market pressure to produce
standard-conforming compilers, for those languages that have
official standards (Ada, C, C++, Fortran, Cobol, etc).

Not Eiffel?

TTBOMK, Eiffel doesn't have an official standard. If there was an ISO
standard, it would naturally fall under JTC1/SC22, but the ISO
JTC1/SC22 web site: http://www.open-std.org/jtc1/sc22/, doesn't mention
Eiffel anywhere.

Searching for Eiffel on the ANSI, ECMA and IEEE web sites fails to turn
up anything positive either -- ANSI and ECMA come up completely dry and
while IEEE cites a number of papers on Eiffel, none that I could find
looked like an official standard.

http://www.eiffel-nice.org/standards/

Eiffel The Language 2nd Printing
Bertrand Meyer's book describes the Eiffel language, and was adopted by
NICE as the language standard.

--
Yermat

[Robert A Duff]

"Jerry Coffin" <jc*****@taeus. com> writes:

ad******@sbcglo bal.net wrote:

"Robert A Duff" <bo*****@shell0 1.TheWorld.com> wrote in message
news:wc******** *****@shell01.T heWorld.com...

...but of course there's a lot of market pressure to produce
standard-conforming compilers, for those languages that have
official standards (Ada, C, C++, Fortran, Cobol, etc).

Not Eiffel?

TTBOMK, Eiffel doesn't have an official standard. If there was an ISO
standard, it would naturally fall under JTC1/SC22, but the ISO
JTC1/SC22 web site: http://www.open-std.org/jtc1/sc22/, doesn't mention
Eiffel anywhere.

Searching for Eiffel on the ANSI, ECMA and IEEE web sites fails to turn
up anything positive either -- ANSI and ECMA come up completely dry and
while IEEE cites a number of papers on Eiffel, none that I could find
looked like an official standard.

I think ECMA is working on an Eiffel standard.

See:

http://www.ecma-international.org/memento/TC39-TG4.htm

- Bob

[Robert A Duff]

az****@yahoo.es (Alberto) writes:

"Dmitry A. Kazakov" <ma*****@dmit ry-kazakov.de> wrote in message news:<1l******* *************** ********@40tude .net>...

But even then bounds checking is not needed for every access. Example:

procedure Dynamic (A : Some_Array) is
subtype Index is Array_Index range A'Range;
J : Index := A'First;

for I in A'Range loop
A (I) := .. -- No checks
...
J := I;
end loop;
A (J) := ... -- Still no checks

C++ completely lacks the notion of constrained subtypes which makes the
above possible.

If Some_Array is any array supplied at run-time, how can the compiler
know what values are stored in A'Range? (I mean, what the bounds of
the array are) It *has* to check these bounds at run-time.

No, that's not correct. Some compilers can and do prove that I is
within the bounds of A, and therefore avoid generating any checking
code. Neither the array bounds, nor the value of I, need be known
at compile time.

In general, if *you* can prove something about a program, then it is
possible to teach a compiler to do so. Not necessarily *feasible*, but
*possible*. This is related to what Appel calls the "full employment
act for compiler writers" or some such -- no matter how smart a compiler
is, it's always possible to write a smarter one.

But in the above code, it is both possible and feasible to eliminate
*all* of the bounds checking. Thus, there's no need to suppress checks
on the above code.

2. C++ is unable to allocate objects of indefinite size on the stack.

Well, we have alloca() for this ;)

Is alloca part of the C++ standard? I thought not, but I could be
wrong. Anyway, alloca doesn't really do all that Ada can do in this
regard (avoiding heap usage for dynamic-sized things). In this case,
the Ada feature is both more efficient and safer than alloca.

- Bob

[Robert A Duff]

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

Ioannis Vranos wrote:

Actually the Boost type that you are probably looking for is:
"uint_value _t: The smallest built-in unsigned integral type that
supports the given value as a maximum. The parameter should be a
positive number."

So the example becomes:

#include <boost/integer.hpp>
int main()
{
using namespace boost;

// Value range 0..16
uint_value_t<16 >::least my_var;

my_var= 9;
}

This is the equivalent of 0..whatever.
Myself thinks though that this whole range specialisation thing is
non-sense for regular application programming at least.

Indeed. :-)

Ah, so Ioannis Vranos agrees with Ioannis Vranos here,
so it must be true? ;-)

Actually, integer subranges are quite useful. For example, in some
cases they allow the compiler to ensure (without any run time checking)
that the integer index into an array matches the bounds of that array.
Including in cases where the bounds are not known at compile time.

- Bob

[Paul Dietz]

ad******@sbcglo bal.net wrote:

Still, when we hold one development environment (an Ada compiler)
to a higher standard, we need to understand that difference when
making comparions. It costs a great deal more money to produce
a compiler that must pass validation (now conformity) than to
create one in which the defects are intended to be discovered
by the users and fixed in some future release.

If one has a copy of the validation test suite, why is it necessary
to wait for the users to find the bugs? Is it that you have to pay
for the cost of fixing the bugs that the users would never encounter?

Paul

[Ioannis Vranos]

Robert A Duff wrote:

Actually, integer subranges are quite useful. For example, in some
cases they allow the compiler to ensure (without any run time checking)
that the integer index into an array matches the bounds of that array.
Including in cases where the bounds are not known at compile time.

OK, however as I have mentioned before, one can also provide this type
of guarantees in C++, without any run-time checks:
#include <vector>
int main()
{
using namespace std;

vector<int> intVector;

for(vector<int> ::size_type i=0; i<intVector.siz e(); ++i)
// ...
}

#include <vector>
int main()
{
using namespace std;

vector<int> intVector;

for(vector<int> ::const_iterato r p= intVector.begin ();
p!=intVector.en d(); ++p)
;// ...
}


// Not real value, for display purposes only
#include <algorithm>
#include <vector>

inline int doubleF(const int &arg) { return 2*arg; }

// ...

vector<int>some Array(10, 1);

// ...

transform( someArray.begin (), someArray.end() ,
someArray.begin (), doubleF );

etc.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

"Ioannis Vranos" <iv*@remove.thi s.grad.com> wrote in message
news:1110326720 .837893@athnrd0 2...

It began as "C with classes", but this does not mean "it was designed
for" that only.

And that is the unfortunate aspect of the language: its foundation on C.

I once heard Stroustrup confess that, if he had had his druthers, he would
not have started with C as the seed language.

Many of the original design ideas for C++ were abandoned to keep the
language more manageable. For example, delegation was an early idea
that failed to make it into the final design. Templates were not in the
C++ language until much later.

C++ continues to evolve, but much of that evolution seems to follow a
course of shoring up things already in the language that don't quite work
as one might prefer, or adding a truss here and a buttress there to
prevent or enable deficiencies in the language; e.g., cast-away const,
a truly silly addition to the language.

Finally, one must give credit and admiration to Dr. Stroustrup for the superb
work he did in leveraging a mediocre language such as C into a language
that has caught on with such a wide audience. One can only wonder, given
his genius, what a great language he might have created if he had not been
an AT&T employee, forced to start with C, those many years ago.

Richard Riehle