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?

[Robert A Duff]

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

kevin cline wrote:

Personally I prefer slimmer languages and fatter libraries whenever
possible.

I agree.
However C++ has also the ideal to be able to write these libraries with
the language itself.

As opposed to... ?

- Bob

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 16:02:43 -0500, Robert A Duff wrote:
<lots of sensible clarification of the issue removed>

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

precisely. That was my point (Friday) about needing proper
language support for associative arrays in both C++ and Ada, or
(as you suggest) lower-level prerequisites. In Ada, maybe it could
be a 'Hash attribute.

I think we can also see clearly how generics/templates are only
superficially equivalent in what programmers demand of them.
The contract model being a big part of the encapsulation process
considered essential by Ada users, but *worse than useless* from
the C++ view.

Thnaks Rob for putting the points more eloquently!
--
Adrian

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

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
concentratin g 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).

And hence why I'm curious exactly which ones are fully standard
conforming, optional parts aside (or at least clearly labelled).
--
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]

Newsgroups: comp.lang.ada,c omp.lang.c++,co mp.realtime,com p.software-eng
Subject: Re: Teaching new tricks to an old dog (C++ -->Ada)
References: <42************ **********@news .optusnet.com.a u> <11************ *********@z14g2 000cwz.googlegr oups.com> <hO**********@e isner.encompass erve.org> <wc************ *@shell01.TheWo rld.com> <11************ *@corp.supernew s.com> <pa************ *************** *@linuxchip.dem on.co.uk.uk.uk> <11************ *@corp.supernew s.com>
From: Robert A Duff <bo*****@shell0 1.TheWorld.com>
Organization: The World Public Access UNIX, Brookline, MA
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Date: 14 Mar 2005 17:35:28 -0500
Message-ID: <wc************ *@shell01.TheWo rld.com>
Lines: 139
--text follows this line--
CTips <ct***@bestweb. net> writes:

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().
Right. Note that multi-level nesting as in this example is rare in
languages that allow nesting. (And of course nonexistent in languages
that don't!) The vast majority of procedures are not nested (level 0),
some are nested (level 1), and extremely few are more nested (level 2 or
more). So to implement this stuff efficiently, the compiler writer
should keep this in mind.
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.
I don't know of any compilers that do that. To make that work, you'd
have to have some way to identify the "right" stack frame, and I can't
think of any way to do that efficiently.
- 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().
That's the method I prefer. The best way to think about it is: the
static link is an extra parameter passed to the called function.
Each nested function needs a parameter that somehow represents its
context.

Given that multi-level nesting is rare, the chain is usually length 1
(or we don't need to do anything at all, for the nonnested ones).
- display: somewhat like the static chain, except its an array instead
of a list
To me, that seems like an attempt to optimize multi-level nesting, which
is why I don't prefer it.
- 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.
Yes, something like that makes sense; I view it as an optimization of
static chains. It's not what I know as "currying", though, which is
something completely different. In the example you gave, you can pass x
and y, not pointers to them.
There were some additional nastinesses dealing with what happens when a
nested function is passed as an argument
It's really no big deal. When passing a nested procedure to an outer
one, you need to pass an extra parameter indicating the enclosing
context. When using static chains, this is just the static link.
Or, in some cases, optimize by doing what you called "currying" above.
(Which is just like optimizing by passing the components of a struct
instead of passing a pointer to it.)

Note that Ada distinguishes (syntactically) the case where the passed
procedure can be nested, and the case where it cannot. The case where
it cannot is handled exactly as in C -- pass just the address of the
procedure's code.

(Actually, that's an oversimplificat ion -- the nonnested case is really
the same-nested case, which includes the C case of nonnested.)

Or, in many cases, inline the whole mess, and there's no call overhead
at all.

Yes, there is some cost -- it complexifies the compiler, for one thing.
But the run-time cost is really near zero.

By the way, there's another method you didn't mention. The gcc dialect
of C supports nested functions (and passing those as parameters), and
they're implemented using trampolines.
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.
Right. But in most cases, you pay nothing, and in the cases where you
pay, you're getting something for it (like, not having to pass extra
parameters, which you would have to pay for instead).
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.
Only for nested functions. And when passing functions as parameters, if
the function *might* be nested (which, in Ada, the compiler knows).
C++ probably left it out because of its C heritage,
Yes.
... while Ada probably
dropped it in because of its Pascal heritage.
Perhaps, but it's not just Pascal. It's pretty much every language from
Algol and Lisp onward. This feature is really extremely useful!
... IMHO, its probably not
worth the cost.

Well, my philosophy is: the (run-time) cost is irrelevant. If you need
some feature, you need it, and if it's not in the language, you have to
implement it yourself, and that will cost at least as much. What's
relevant is distributed overhead: if you pay the cost for a feature when
you *don't* use a feature, then that's a good reason to leave it out of
the language. IMHO, to argue against nested procedures, you have to
either argue that they're not very useful, or you have to argue that
they cause distributed overhead (cost when you don't need them). You
can't just argue that they're slow, because the alternatives
(implemented by hand) are just as slow.

- Bob

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

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!

I am not sure I understood what you are saying. First, map is not using
hash, so the identifier hash may be misleading.

Secondly you can either specify an operator<, or a predicate like this:
#include <ctime>
#include <map>

struct interval
{
std::tm start, finish;
};

struct IntervalLessCom pare
{
inline bool operator() (interval a, interval b) const
{
using namespace std;

return difftime( mktime(&a.finis h), mktime(&a.start ) ) <
difftime( mktime(&b.finis h), mktime(&b.start ) );
}
};

int main()
{
using namespace std;

map<interval, float, IntervalLessCom pare> somemap;

interval fred;

// set fred here!

somemap[fred] = 0.123f;
}


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Randy Brukardt]

"Jerry Coffin" <jc*****@taeus. com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .
....

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.

This statement is false. I was going to try to explain precisely what
happened, but it probably is better to just point to the articles on that
topic that were published at the time. See:
http://www.adaic.com/compilers/index.html
and in particular:
http://www.adaic.com/compilers/acaa.html

The ARA funding of the ACAA continues today; the process is alive and well.
There has been a significant drop off in formal testing, supposedly because
customers aren't demanding it as much as they did in the past. (Personally,
I think that is a good thing, because it lets implementers concentrate on
what's important to their customers rather than formal testing -- even
though it means I make less money. It's also less necessary because all Ada
vendors run the test suite regularly as part of their in-house regression
tests -- there isn't anyone trying to get by without conforming.)

Randy Brukardt
ACAA Technical Agent

[Martin Dowie]

Greg Comeau wrote:

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

Because the "Ada Compiler Assesment Authority" authorised it.

Some usefull links:
http://www.ada-auth.org/info.html
http://www.adaic.com/compilers/testing.html
http://www.adalog.fr/acal2.htm

Cheers

-- Martin

[Ioannis Vranos]

Robert A Duff wrote:

However C++ has also the ideal to be able to write these libraries with
the language itself.

As opposed to... ?

.... other slimmer languages using "exotic" libraries.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Randy Brukardt]

"Greg Comeau" <co****@panix.c om> wrote in message
news:d1******** **@panix1.panix .com...

In article <at***********@ hunter.axlog.fr >,

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

See the links I posted earlier. The ACAA is an instantiation of ISO 18009
funded by the Ada Resource Association. AdaLog is an accredited ACAL under
ISO 18009.

Note that AJPO transferred pretty much all of its programs and materials to
the ARA, including its website (www.adaic.org), validation testing,
marketing programs, and so on. Anyway, it seemed better to put "conformity
assessment" under an International Standard rather than a program managed by
a specific country.

Randy Brukardt

[Robert A Duff]

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

Robert A Duff wrote:

However C++ has also the ideal to be able to write these libraries with
the language itself.

As opposed to... ?

... other slimmer languages using "exotic" libraries.

Such as... ?

I'm still not understanding your point. Are you referring to the fact
that the Java garbage collector cannot reasonably be implemented in
Java, and things like that?

- Bob