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?

[Greg Comeau]

In article <wc************ *@shell01.TheWo rld.com>,
Robert A Duff <bo*****@shell0 1.TheWorld.com> wrote:

co****@panix.c om (Greg Comeau) writes:

>>>> Out of curiosity how old is the ACATS test, and how many
>>>> compilers currently pass it?
Still looking for this number if anybody has it handy.

Not sure which number you're looking for...

How many current compiler pass current ACATS test,
at least those that are required.
...
As I said elsewhere, passing 100% of the ACATS, or 100% of any other
test suite, does not guarantee the absense of bugs (obviously).
Obviously, indeed

>BTW: In the past it was Ada(tm) and only compilers with pass the test where
>allowed to use the trademark Ada. For better or worse that is gone now -
>and with it the need for a vendor to publish the result.

These points certainly "lessen the gap" then (if there was one)
and make it much closer to the C++ situation then.

What is the C++ situation? Is there a conformance test suite available?
Is it free? What about C (same questions)? (Sorry, if you already
answered that.)

One's leaping right to mind are Perennial, PlumHall and Dinkumware's,
as commercial products. There's other too, and other open source
regressions, etc too.
By the way, the idea that Ada(tm) compilers had to pass some tests is
long, long gone. It was a fairly silly idea, anyway, and totally
unenforceabl e. Nobody's stopping anybody from producing a compiler for
Ada-except-some-diffs, or C++-except-some-diffs, for that matter.

Yes, I'm hearing that loud and clear.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Robert A Duff]

Ki*******@SpamC op.net (Larry Kilgallen) writes:

Anyway, nested functions are really nested in any useful sense if you ^not
Of course I meant "not" above. Sorry again.
can't do uplevel addressing, right?
I much prefer that capability, but in Bliss (which lacks uplevel addressing)

Hmm. I had forgotten that about Bliss. I did a fair amount of Bliss
programming a long time ago...

So it's sort of like a "static" variable declared inside a C function --
it's nested with respect to visibility, but its lifetime is not,
so its run-time semantics are just as if declared at top level.
there is some benefit provided by just the reduced visibility of the
nested function. I know for sure that I can call my nested function
RETRIEVE_STATUS without worrying about a conflict with something else
of the first name.

This is _certainly_ not a Bliss vs. Ada argument, but for me it is
a Bliss vs. C argument.

Please remember, however, that I only mentioned it because you asked :-)

Well thanks for answering. ;-)

- Bob

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 19:29:25 +0000, Dr. Adrian Wrigley wrote:

I'm sorry I can't explain this any better!
(should I give a code example?)

OK. How about a trivial but reasonable example:

#include <time.h>
#include <map>

struct interval {
tm start, finish;
};

int main()
{
std::map<interv al, float> hash;
interval fred;

// set fred here!

hash[fred] = 0.123;
}

No suitable place to put the compare operator!
--
Adrian

[kevin cline]

Martin Dowie wrote:

Jerry Coffin wrote:

Pascal Obry wrote:

"Jerry Coffin" <jc*****@taeus. com> writes:
Your claim of fewer bugs is just the sort of unsupported anti-C
comment we see all the time.

Just plain wrong, there is data (a PHD) see
http://www.adaic.com/whyada/ada-vs-c/cada_art.html

Ok, what about this paper:
http://www.praxis-his.com/pdfs/c_by_...er_cheaper.pdf

In particular the company audited by the UK MoD on the 3rd page

showed interesting results. I work for the company audited and I'm sure the
audit is post-1995 by some margin (when I was no longer working there), and by your own argument, by 1990 the compilers were pretty close to
standard C, yet this study still found a 10*defect rate in C than in
Ada... and a 100* defect rate compared to SPARK...

Yet, this sort of report seems all to common to me. Every language since 'C' has had at least 1 report that shows how brilliant it is at compared to 'C', yet 'C' is still the most widely spread language. Why?

I think we perhaps need a psychologists view rather than looking at
language differences. Are humans 'hooked' on tracking down /really/
tricky null pointer dereference problems? Is it really just a fight for 'silver back status' coz 'my programs compile to 1 long word less than yours'?...

No, people are hooked on getting work done with what they perceive to
be the least possible effort and minimal risk. So they pick what they
know, what their colleagues know, what has been known to work in the
past in their application domain. Ada rarely enters the picture. They
don't know Ada, no one they know uses Ada, no one they read advocates
Ada.

For a lot of commerical applications Perl or Python or Ruby or another
higher level language would be considerably better than Java, or C++,
or C#, but mostly they aren't used either. Even though they are
considerably more popular than Ada, they still aren't popular enough
for risk-averse project managers.

[Greg Comeau]

In article <at***********@ hunter.axlog.fr >,
Jean-Pierre Rosen <ro***@adalog.f r> wrote:

Jerry Coffin a écrit :

Let's address the Ada side first. Official Ada validation was done
under the auspices of NIST, who delegated this task to the Ada Joint
Program Office. The AJPO ceased to exist years ago, and the job was
never turned over to anybody else when that happened. Meanwhile, NIST
has discontinued _all_ of its compiler validation programs, not just
the Ada program. Currently, both the ISO standard at a number of FIPS
pubs _require_ Ada compilers to be officially validated, but at least
in the US, there is absolutely NO agency to do that.

I can assure you that there is still one official ACAL (laboratory for
performing validation): Adalog, that's my company!

OK, it's not in the US. So what? Ada is an international standard.

Other posts seems to disagree. Please clarify for us.
Also include how and why your company is the _official_ lab.
(I'm not challenging you, but seems to me a mixed message
is coming through this thread.)
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[kevin cline]

Dr. Adrian Wrigley wrote:

On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:

Dr. Adrian Wrigley wrote:

the problem as I suggested in my previous post is that you have to
pass in the comparison operator or hash function down the tree
of template/generic instantiation, (composing them along the way)
if you want to use maps/hashes.
In the standard library containers and algorithms case you do not pass any function to the container. operator< is implicitly used.

The comparison operator here seems to be a generic formal function
parameter with a default value. This must be available at

instantiation. The operator becomes part of the interface (implicitly or explicitly) for any code instantiating the std::map. Where does the code for the
comparison operator go? It *has* to go at the point the class
is defined.

Actually, it doesn't. If not defined as a member function in the
class, it can be defined as a free function wherever convenient. Or a
custom comparison function can be defined and specified in the
instantiation.

Either this:

class Stuff {
public:
bool operator<(const Stuff& rhs);
};

or this:

bool operator<(const Stuff& lhs, const Stuff& rhs);

will work with this:

std::set<Stuff> allStuff;

Or you can define a special comparator to be used for a particular
instantiation, like this:

struct compareStuff()
{
bool operator()(cons t Stuff& lhs, const Stuff& rhs) { ... }
}

std::set<Stuff, compareStuff> zeds;

[Robert A Duff]

"Dmitry A. Kazakov" <ma*****@dmit ry-kazakov.de> writes:

On Mon, 14 Mar 2005 19:29:25 GMT, Dr. Adrian Wrigley wrote:

On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote:

Dr. Adrian Wrigley wrote:

the problem as I suggested in my previous post is that you have to
pass in the comparison operator or hash function down the tree
of template/generic instantiation, (composing them along the way)
if you want to use maps/hashes.

In the standard library containers and algorithms case you do not pass
any function to the container. operator< is implicitly used.

The fact that "<" can be implicitly passed to the template/generic (in
C++/Ada) is not relevant; Dr. Wrigley's point is that it has to be
there.
The comparison operator here seems to be a generic formal function
parameter with a default value. This must be available at instantiation.
The operator becomes part of the interface (implicitly or explicitly) for
any code instantiating the std::map. Where does the code for the
comparison operator go? It *has* to go at the point the class
is defined.
Because the "<" (or Hash) needs to know the internals of the thing.

In other words, at the point where you declare a type, you have to think
ahead: this type might want to live inside one of those containers, so
I'd better define the necessary operations.

I agree -- that's a pain.

The only way around it, it seems to me, is to have the compiler
automatically create a hash function (or something) for every type --
after all, you can't expect to create these kinds of containers without
a hash function (or something, like "<"), whether the user is required
to write it or not. Lots of languages do something like that, but I
don't know of any such that emphasize efficiency like C++ and Ada.
Also, in the "<" case, the "<" might mean something important
(so you can iterate through the container in a sensible order),
and I don't see how the compiler can be expected to guess what order
that is.
...This could be at the other end of a hierarchy of
generic instantiations. The result is that the implementation
requirement (needs a comparison operator) has propagated up the
generic hierarchy to some otherwise completely independent code as an
interface requirement. I'm sorry I can't explain this any better!

I think I understand what you mean.
It can be formulated in two words: "contract model" is what C++ templates
lack.

Which is both a benefit and a drawback. C++ templates are somewhat more
powerful that Ada generics, because of the lack of contract model, and
implicit instantiation.

But I don't think that addresses Dr. Wrigley's complaint (which applies
to both Ada and C++).

- Bob

[CTips]

Dr. Adrian Wrigley wrote:

On Sat, 12 Mar 2005 12:59:31 -0500, CTips wrote:

Robert A Duff wrote:

Ki*******@Sp amCop.net (Larry Kilgallen) writes:

Even Bliss has nested functions. What Ada has that Pascal has in addition
to nested functions is uplevel addressing, allowing an inner function to
access data declared in outer scopes.
Heh? Pascal has that. In fact, practically every programming language
outside the C family has this feature. It's quite useful -- almost
essential in multi-threaded programs.

- Bob

Yeah, and don't ask what it costs you. I'd carefully forgotten about all
the grungy details about displays and static/dynamic chaining, and you
had to remind me. I particularily like solutions that reserves a
register for the top-of-display/top-of-static-chain. Thats right - blow
away a register for that. And then of course the cost of
maintaining/walking those structures.

If you need thread-private storage, there are *much* cheaper solutions.

isn't uplevel addressing usually zero cost? Are you saying it is
expensive whenever you use it? Or expensive on all programs, whether
or not it is used? Is it absent from C++ because of cost?
(I'm sure Robert understands this far better than I!)

My knowledge of this is a little dated and hazy, so I could be wrong.

If we're doing something like:
foo()
{
int x, y;
bar()
{
int y;
gah()
{
use(x), use(y);
}
}
}

then, at run-time, in use(x), x comes from the stack-frame of the
nearest invocation of foo() on the stack, and in use(y), y comes from
the stack-frame of the nearest invocation of bar().

There has to be a mechanism to identify the nearest invocation of
foo()/bar(). There are, if I remember correctly, 4 mechanisms to find
the invocation:
- dynamic chaining: you just follow the back-chain pointers, stepping
through all stack frames, till you come to the right stack frame.
- static chianing: you maintain a separate chain (the static chain) that
directly link to the stack frame of the enclosing functions. Thus the
static chain for gah() would have the last invocation of bar() followed
by the last invocation of foo().
- display: somewhat like the static chain, except its an array instead
of a list
- currying (?): this one I'm really hazy about, but, roughly, you passed
pointers to the correct uplevel variables as extra arguments to the
functions. Thus bar would be passed the pointer to x and gah would be
passed pointers to x and y, as well as their other arguments, or
something like that.

There were some additional nastinesses dealing with what happens when a
nested function is passed as an argument

Depending on the techinques, you either pay whenever you access
variables of enclosing functions, or you pay to maintain the
data-structures [static-chain,display] which make this access cheaper,
or both.

On some implementations (on RISC architectures) a register is reserved
for the static-chain. This means one less register for *every* function
(or maybe only for enclosed functions?) when used with a language that
support this kind of nested functions.

C++ probably left it out because of its C heritage, while Ada probably
dropped it in because of its Pascal heritage. IMHO, its probably not
worth the cost.

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 13:02:10 -0800, kevin cline wrote:

Dr. Adrian Wrigley wrote:

any code instantiating the std::map. Where does the code for the
comparison operator go? It *has* to go at the point the class
is defined.

Actually, it doesn't. If not defined as a member function in the
class, it can be defined as a free function wherever convenient. Or a
custom comparison function can be defined and specified in the
instantiation.

OK. Maybe there are circumstances where it could, in practice, go
somewhere else. If some of the sorted values are in the private
part, I guess you could use a friend class(?). But in the particular
case of generic hierarchies, there is probably nowhere convenient :(
Even in simple cases, the encapsulation has to be broken (see the
time interval example).
--
Adrian

[Robert A Duff]

co****@panix.co m (Greg Comeau) writes:

In article <wc************ *@shell01.TheWo rld.com>,
Robert A Duff <bo*****@shell0 1.TheWorld.com> wrote:

co****@panix.c om (Greg Comeau) writes:

>>>> Out of curiosity how old is the ACATS test, and how many
>>>> compilers currently pass it?

Still looking for this number if anybody has it handy.
Not sure which number you're looking for...

How many current compiler pass current ACATS test,
at least those that are required.

Well, let's see. Off the top of my head, Ada compilers are available
from Sofcheck (that's my company), AdaCore (that's the free software
version; they make their money by providing support), Greenhills
(which uses the SofCheck Ada front end, and supports many embedded
targets), Aonix (also uses the SofCheck front end), RR Software,
DDC-I, ICSC (sp?), IBM... (Did I forget some?)

I don't know which ones pass (the required portion of) the ACATS.
My guess is: all of them.

(The reason there are ACATS tests that are not required is that some
portions of the language standard are optional. The standard has
optional annexes for various specialized purposes: real-time,
information systems, safety critical, etc.)

By the way, SofCheck's current focus is not Ada compilers: we're
concentrating on static analysis tools for Java and Ada and eventually
other languages such as C++. But we still make most of our revenue
from the compiler side of the business.

By the way, the idea that Ada(tm) compilers had to pass some tests is
long, long gone. It was a fairly silly idea, anyway, and totally
unenforceabl e. Nobody's stopping anybody from producing a compiler for
Ada-except-some-diffs, or C++-except-some-diffs, for that matter.

....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).
Yes, I'm hearing that loud and clear.

- Bob