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?

[Jerry Coffin]

Ioannis Vranos wrote:

[ ... ]

unsigned char *a = reinterpret_cas t<char *>(&x);
unsigned char *a = reinterpret_cas t<unsigned char *>(&x);

Oops -- quite right. Fortunately, despite it's reputed lack of safety,
any properly-functioning C++ compiler would have caught my mistake had
it been in real code.

[ ... ]
Also since Ada is more ancient than C++ in terms of a final standard,
we can expect that some things are "more ancient", but it is still
an interesting language since it can do low level stuff.
I'm not sure "ancient" applies to either -- at least the last time I
noticed, the most recent Ada standard was approved in 1995, which is
marginally older than the C++ standard. I'm not really sure this means
a lot though -- most of the basic ideas of C++ were fixed by then in
any case. Certainly there were changes in the text of the rules after
that point, but most of these were to get the rules to require what had
already been decided upon, not things that were intended to change the
language.
I am not sure it is "safer" than C++ too, I am suspicious of "safe"
languages.

The first problem is to define what you mean by safety. Bjarne has been
fairly explicit that most safety features in C++ are intended to
prevent accidents, not intentional subversion. It's always seemed to me
that Ada has had a rather muddled idea of the "threat model", so the
language features have never been entirely aligned to a single intent.
Some parts appear intended to prevent accidents, but are quite easy to
subvert when one wishes to do so. Other parts appear to have been
designed with the intent of preventing even intentional subversion, but
fail to do so, and simply render some things quite a bit uglier than
there seems to be good reason for.

In fairness, I should add that my personal experiece with Ada was
almost entirely with the 1983 version, so it's entirely possible that
at least some of these have been fixed -- OTOH, looking at the code
snippets posted to this thread, it looks like at least some of the
ugliness remains.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Peter Amey]

Hans Malherbe wrote:

support efficient, real-time safe environments

Can you explain the "real-time" part?

Reading this thread, it seems to me Ada's focus is on safety rather
than efficiency.
These safety constraints also tend to limit expressiveness. Not that
safety is bad, just that it's not free.

Actually, a close reading of the thread should have made it clear that
the additional safety is indeed "free". Since the majority of Ada's
checks are compile time they do not impact on run-time efficiency.
Where Ada's goals can only be met by run-time checks these are no more
expensive than equivalent manually-inserted checks in any other language
(and are often less because Ada provides the compiler with more
information by which to judge when they can safely be optimised away).
They can, in any case be turned off if the user requires a different
performance/safety tradeoff.

It should also have been clear from the thread that Ada imposes no
limits on expressiveness.

Can you say what led you to the opposite conclusion?

Peter

[Larry Kilgallen]

In article <11************ **********@o13g 2000cwo.googleg roups.com>, "Hans Malherbe" <ha***********@ gmail.com> writes:

support efficient, real-time safe environments
Can you explain the "real-time" part?

Reading this thread, it seems to me Ada's focus is on safety rather
than efficiency.

Many of these checks have been described as being compile-time checks.
A goal of fast compiles should not dominate.
These safety constraints also tend to limit expressiveness. Not that
safety is bad, just that it's not free.

Nobody has come up with something that cannot be expressed in Ada (or
in C++ for that matter). Ada code is more verbose, on the grounds that
code is read more often than it is written (or at least it should be).

[Dr. Adrian Wrigley]

On Tue, 08 Mar 2005 15:27:35 +0200, Ioannis Vranos wrote:

Dr. Adrian Wrigley wrote:

C++ was designed to produce an object-orientated
extension to C.

An all too common misconception.

enlighten us please!

C++ is a multiparadigm language and supports 4 paradigms. Each paradigm
is supported *well* with optimal space and time efficiencies.

It does not enforce a specific paradigm, but allows the mixing of them
as the programmer thinks it fits better for a specific problem.

This is is well known.

I was asking for my misconception on what *C++ was designed for* to
be dispelled.
--
Adrian

[Pascal Obry]

Peter Amey <pe********@pra xis-cs.co.uk> writes:

manually-inserted checks in any other language (and are often less because
Ada provides the compiler with more information by which to judge when they
can safely be optimised away).

For example (if you ask):

type Table is array (1 .. 10) of Integer;

Data : Table;

for K in Data'Range loop
if Data (K) = 1 then
...
end if;
end loop;

There is no need to check K validity inside the loop as "Data (K)" is always
correct by definition (K in Data'Range). Just an example.

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

[CTips]

Peter Amey wrote:

Hans Malherbe wrote:

support efficient, real-time safe environments
Can you explain the "real-time" part?

Reading this thread, it seems to me Ada's focus is on safety rather
than efficiency.
These safety constraints also tend to limit expressiveness. Not that
safety is bad, just that it's not free.

Actually, a close reading of the thread should have made it clear that
the additional safety is indeed "free".

Free? Well, lets look at one particular issue: pointers to arbitrary
locations. In C, its a common idiom to do the following:
foo(int * p)
{
int * z;
for( i ... ) {
... p[i]...;
}
z = p;
}

...
foo( &x[lo] );
...

Now, how can *any* language check to see that p[i] is within bounds?

The usual solution is to pass p as a "handle"; basically, pass two
pointers, one of which is the pointer to the descriptor of the
containing "object" (which could be x or something containing x), or
alternatively, pass a pointer to a record that contains x and p. z, in
particular, will have to be a 2 element record, again containing x and p.

A dereference via z will have to become a double dereference; first load
p from z then load from p.

Not quite free.
Since the majority of Ada's
checks are compile time they do not impact on run-time efficiency.
Where Ada's goals can only be met by run-time checks these are no more
expensive than equivalent manually-inserted checks in any other language
(and are often less because Ada provides the compiler with more
information by which to judge when they can safely be optimised away).
Bullsh*t. In several ways, of which two are:
- Usually the checks will be added every place they are needed, and then
the usual optimizations will be used to eliminate them. In other words,
if one adds the checks manually, the compiler should eliminate them
identically.
- Going back to the problem of finding the countaining object for some
pointer. If one is adding the code by hand, one can use several options
NOT available to a compiler.
* what if z always points to objects inside x (but the compiler can't
figure it out).
* what if the containing object for p is always allocated on some 2^n
byte boundary?

There are other interesting things one can do for safety that are less
memory/CPU intensive than what a language can give you automatically.

Have a look at http://users.bestweb.net/~ctips for some of the ideas.
They can, in any case be turned off if the user requires a different
performance/safety tradeoff.
Are you sure? Do I have to recompile the whole program in that case? Or
reannotate the whole program? The above "handles" case is particularily
pernicious. If a sub-program is compiled to not expect handles [because
we just turned off that protection feature], but its caller is still
passing handles, well - interesting things will ensue.
It should also have been clear from the thread that Ada imposes no
limits on expressiveness.
How easy is it to build an arena allocator in Ada?

Given a processor with load-word-locked and store-word-conditional, how
would I build an atomic increment function?
Can you say what led you to the opposite conclusion?

Peter

[Pascal Obry]

CTips <ct***@bestweb. net> writes:

Free? Well, lets look at one particular issue: pointers to arbitrary
locations. In C, its a common idiom to do the following:
foo(int * p)
{
int * z;
for( i ... ) {
... p[i]...;
}
z = p;
}

...
foo( &x[lo] );
...

Now, how can *any* language check to see that p[i] is within bounds?
Good you asked! Let's code this example in Ada (using Ada and
not C/C++ style, in Ada for the above example we do not need a pointer):

type T is array (Positive range <>) of Integer;

procedure Foo (P : in out T) is
Z : Positive;
begin
for I in P'Range loop
... P(i)...;
-- Here P(i) is always within the bounds, no check needed.
end loop;
Z := P'First;
end Foo;

...

Foo (X (Lo .. X'Last));
Bullsh*t. In several ways, of which two are:

Given your assumption about maybe you just don't know Ada.

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

[Ludovic Brenta]

John Hudak writes:

What??????????? ??????????????? ??????????????? ???????? Assembly
language? powerful? If you decide to write a X GUI interface in
assembly, I'll check in on you in 20 years to see how your
doing.... Higher level languages handle broader abstract concepts
better than low level languages. Assembly is great if you are
optimizing device drivers or banging bits at the hardware register
level...not good at implementing scientific algorithms, GUIs,
databases, etc. There are thousands of reasearch papers that extol
the problems of assembly language approach to things, and yes, there
are places and reasons to use it, but classifying it as a 'higher
level language' and something more powerful is incorrect....
-John

I think the problem is to define what everyone means by "powerful".

If by "powerful" I mean "I can do exactly anything I want", or "I can
get the most out of my hardware", then assembly is the most powerful
language.

If OTOH "powerful" means "I can program quickly", then assembly is not
powerful, but e.g. SQL or Delphi are.

--
Ludovic Brenta.

[Ludovic Brenta]

"Jerry Coffin" writes:

In fairness, I should add that my personal experiece with Ada was
almost entirely with the 1983 version, so it's entirely possible that
at least some of these have been fixed -- OTOH, looking at the code
snippets posted to this thread, it looks like at least some of the
ugliness remains.

The "use type" feature of Ada 95 alone makes Ada 95 *much* more
pleasant to program with. Check it out. And yes, we allow it in our
coding standards :)

--
Ludovic Brenta.

[Ludovic Brenta]

"Jerry Coffin" writes:

Ludovic Brenta wrote:

I could make the code less verbose by using use clauses, similar to
"using namespace std" which you seem fond of. In avionics, our
coding standards forbid that because we want everything to be
explicit.

A poor idea. Just for example, consider writing a generic sorting
function. It needs to swap items that it's sorting. In well-written
C++, this will often be done with a using clause. Specifically, if
the type of items has provided its own specialized version of swap,
then my sorting functino should use that, but otherwise it should
use std::swap to swap them.

I try to specify whatever_type:: swap(x,y), then compilation will
fail if the type has not provided a swap function. Conversely, if I
specify std::swap(x,y), then the specialized swap function won't be
used for those types that provide one.

Ada requires explicit instanciation of all templates, so there is no
"default". We do not have problems using fully-qualified names.

Ada 95's object-oriented features do not suffer from this either.

package P is
type Base is tagged null record;

procedure Method (B : in Base);
end P;
with P;
package Q is
type Derived is new P.Base with private;

procedure Method (B : in Derived); -- overloads P.Method
private
-- omitted
end Q;
with P;
procedure Dynamic_Dispatc h (B : in Base'Class) is
begin
P.Method (B); -- [1]
end Dynamic_Dispatc h;

The procedure Dynamic_Dispatc h does not see package Q, yet it can call
Q.Derived if it receives an instance of Q.Derived as its parameter.
This, *even* without a use clause.

--
Ludovic Brenta.