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 <d1**********@sparta.btinternet.com>,
Martin Dowie <ma**********@btopenworld.com> wrote:

Greg Comeau wrote:

In article <14****************@linux1.krischik.com>,
Martin Krischik <ma****@krischik.com> wrote:

And they havn't got 100% compliance - as the Ada compiler vendors
have. And they can indedd claim that - Ada has the ACATS test -
pass the test you are 100% compliant - fail the thest and (almost)
no customer will consider your offer.
Out of curiosity how old is the ACATS test, and how many
compilers currently pass it?

The latest (I believe) is dated 2002 but will certainly be getting
updated to test Ada2005. See http://www.ada-auth.org/acats.html

Ok.
All compiler vendors claim some level of conformance
In what ways? This sounds like a different statement
than I thought others were saying/implying.
and some publish their results.
Again, seems a different statement.
Also, all compiler vendors will have a large number of
suplimentary tests of there own. These tend to include
propriatory code from customers, so usually aren't published.

I'm sure.

I'm also sure this is all workable, and to work well.
As I'm sure it's not the only way to do it (not saying
you said it was, just adding to the table).
--
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?

[Greg Comeau]

In article <32****************@linux1.krischik.com>,
Martin Krischik <ma****@krischik.com> wrote:

Robert A Duff wrote:

Martin Krischik <ma****@krischik.com> writes:

And they havn't got 100% compliance - as the Ada compiler vendors have.
And they can indedd claim that - Ada has the ACATS test - pass the test
you are 100% compliant - fail the thest and (almost) no customer will
consider your offer.
Now wait. Let's be fair. Sure, the ACATS test suite is a good thing.
But no test suite can ensure 100% compliance with the language
standard. Ada compilers do have bugs that are not caught by the ACATS!

Shure, you are right. However in the end the 100% stuff is all about
marketing - as you said - no compiler is bug free. And in fact nowadays
most of the "chosing a compiler" stuff is about marketing. Not the best
wins but the one average one with the best marketing does.

And don't forget comments such as that found in
http://www.ada-auth.org/acats.html: "Formal test disputes should
submitted to the agent ..." meaning bugs and other things can
pop up in other areas too.
And here a CCATS and C++CATS would help a lot. Or could you imagine
any Ada vendor not submitting to running the ACATS?
Probably can't imagine it, but in the end, the playing field
seem level.
Note to the C/C++ community: when we speak of ACATS we also speak of the Ada
Conformity Assessment Authority (http://www.ada-auth.org/) which actualy
runs the test. Shure anybody can run the test (i.E. with gcc you use "make
-C gcc check-ada" - you need configured gcc sources and a gcc with Ada
enabled) but that is of no marketing value.

Probably. FWIW, C++ has always succeeded against horrible
marketing. It's unclear whether that is a plus or not,
or whether some other way is.
--
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?

[Martin Krischik]

Ioannis Vranos wrote:

Martin Krischik wrote:

C:\c>g++ temp.cpp -o temp.exe
temp.cpp: In function `int main()':
temp.cpp:7: error: invalid conversion from `int' to `main()::four_val'

True - C++ won't convert int to enum either without a static_cast. You
know what I realy miss in C++: dynamic_cast for discreed number:

long X = f();
short Y = dynamic_cast <short> (X);

with a throw range_error when X is to large for Y.

Yes - I have a template for that. But a template need two parameters
<from_type, to_type> and won't optimize as well as a build in function.
And with -W3 you need a lot of specialized versions to avoid all sorts of
"conditional ist constant" warnings.

I am not convinced yet this integer range topic is that a big issue.
The JPEC viruses work in integer range overruns - and that is an issue since
a virus inside an JPEC picture is nasty. Every Web-Page has dozends of
JPEC's - no web browser would consider a JPEC a security risc.
One
can easily write his own test routine (function, template), if the
default provided assert() doesn't do the job.

But assert() only work if the programmer won't forget to insert one. And the
programmers for libjpec for Linux as well as the Microsoft employees which
did a similar lib for Windows forgot.

Not one pogrammer forgot: both *teams* forgot. Not matter if OpenSource team
or comertial team - both forgot to check the integer range inside a JPEC
picture.

For this I go for the template version - and I do indeed have a template
called Ada::Range for C++. And this template can check any range (i.E.
typedef Ada::Range <short, 1, 31> Day_Of_Month;) and not only short, long
overruns. Very helpfull indeed.

And yes, I have a template called numeric_cast <class From, class To> as
well - just build in would be better.

Martin
--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Martin Krischik]

Greg Comeau wrote:

In article <d1**********@sparta.btinternet.com>,
Martin Dowie <ma**********@btopenworld.com> wrote:

Greg Comeau wrote:

In article <14****************@linux1.krischik.com>,
Martin Krischik <ma****@krischik.com> wrote: And they havn't got 100% compliance - as the Ada compiler vendors
have. And they can indedd claim that - Ada has the ACATS test -
pass the test you are 100% compliant - fail the thest and (almost)
no customer will consider your offer.

Out of curiosity how old is the ACATS test, and how many
compilers currently pass it?
The latest (I believe) is dated 2002 but will certainly be getting
updated to test Ada2005. See http://www.ada-auth.org/acats.html

Ok.

All compiler vendors claim some level of conformance

In what ways? This sounds like a different statement
than I thought others were saying/implying.

The Ada standart consists of the core language and optional features like
real-time system and distributed systems.

and some publish their results. Again, seems a different statement.

You might want to read the first chapter of http://www.ada-auth.org. Usualy
the test is done by third part laboratories and then the vendor publish
"pass" for there major releases - but they might not publish for
intermediate releases :-( .

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.

Also: The test is OpenSource and it is even part the gcc source tree - so if
you have the gcc sources handy you can just run the test yourself.
Also, all compiler vendors will have a large number of
suplimentary tests of there own. These tend to include
propriatory code from customers, so usually aren't published.

I'm sure.

I'm also sure this is all workable, and to work well.
As I'm sure it's not the only way to do it (not saying
you said it was, just adding to the table).

The important point that it puts more pressure on the vendors as most
customers won't consider a compiler which won't pass the test.

Martin
--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Martin Dowie]

>>>All compiler vendors claim some level of conformance

In what ways? This sounds like a different statement
than I thought others were saying/implying.

The Ada standart consists of the core language and optional features like
real-time system and distributed systems.

and some publish their results.

Again, seems a different statement.

I only meant "publish" as in 'here's our results on our website'. I'm
sure all vendors would make their results available if you asked their
sales/marketing/support.

Cheers

-- Martin

[Jerry Coffin]

Martin Krischik wrote:

[ ... ]

Did they? Or did they just implemented some 80% of the new features?
My experience with C/C++ (and I have 10 years + of that) is that at
no time there was a fully compiant C compiler available. There where
allways a lot of compiler avaliable who claimed to be
<small>almost</small> complinant - but never one which realy was.

Partily because - unlike Ada (http://en.wikipedia.org/wiki/ISO_18009)
- there is not official testsuite to test a C/C++ compiler and
runtime library. Such an official testsuite would do C/C++ all sorts
of good.
I'm quite impressed with the statements above -- lots of Usenet posts
contain errors, but most of them are pretty obvious. You've managed to
fit more plausibile-sounding errors into fewer sentences than nearly
any other post I've ever seen.

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.

The situation on the C side isn't nearly as different as you seem to
think. After the C standard was published, NIST and BSI (to name only
two that I know of with certainty) started doing validation of C
compilers. BSI certified at least one C implementation in 1990, the
same year the ISO C standard was approved. While that first one was for
code-checking, not production of executables, other implementations
(e.g. at least one version from Borland) were certified as well.

As mentioned above, NIST no longer validates/certifies compilers, so at
least in the US, there is no such thing as an officially validated
compiler for C, Ada, or any other language.
What do you mean by "exists today"? C99 is 5 years old and still no\
compiler is available which support all C99 features. "restrict" -
missing in MS-C (even thrue restrict can be implemented as "no
operation") - VA - arrays (savety critical feature) - missing in
MS-C, buggy in GCC.
I take it you've never used or even tested the Comeau compiler?
Maybe just maybe - if there realy was any standart compiler available
- but there isn't - the C/C++ compiler vendors are allways one
release behind the actual ISO standart.
I see Greg has entered the thread, so he can speak for himself, but
unless memory serves me particularly poorly today, he had C++ 2003
implemented _before_ it was officially approved.

In fairness, I should add that I found a _few_ defects in the Borland
compiler that was certified -- but back when I worked in Ada, I found
defects in every certified Ada compiler I used as well. In both cases
the defects were small and easily avoided, but the defects in the C
compilers were smaller and more easily avoided.

[ ... ]
It is true that a programming language need some minimum features set
to be usefull. And that feature set is a lot larger then most belive.
If a successfull language does not provide that set it will be bolted
on later. If anything the current C/C++ ISO standards clearly show'
that the advocates for slim languages hat been wrong all along.

More nonsense, I'm afraid. First of all, the argument is defective from
the beginning: changes in C and/or C++ absolutely cannot prove anything
about languages in general. Second, some extremely slim languages have
clearly been useful at times, easily disproving your conclusion on
minimum feature sets as well.

None of this proves, or even provides evidence, directly related to
what is claimed by most advocates of smaller languages. Most have said,
for example, that all else being equal, a smaller feature set is easier
to understand completely. Now you may be convinced that a larger
feature set outweighs this fact, and you might even be right -- but
that doesn't make them wrong.

IMO, arguments of the benefits of "small" ("slim", etc.) vs. larger
languages mostly miss the point though. IMO, there's a much more
fundamental and useful distinction to be considered. That is the
distinction between those where the language itself is the major
player, and those were the language is mostly a way of producing and/or
using libraries.

Ada certainly provides facilities useful for writing libraries, but at
least to me seems to fall into the former group -- it works well for
writing code directly, but attempting to write good libraries in it
tends to be frustrating.

C++, while certainly providing some features useful for direct coding,
is strongly oriented toward the language providing facilities for
building libraries, and much (in many cases, MOST) of what the end-user
does is uses the libraries.

Looking at things from this perspective, Ada may be the last of its
line. 30 years ago, Lisp was nearly the only library-oriented language,
with a miniscule market share.

Now, the library oriented languages dominate. Fortran and Cobol may
never die, but they're certainly not the market leaders they once were.
PL/I is dead, and Ada is hardly dominant. C++ has already been
mentioned. Java is a fairly small language with a huge library. The
next obvious step is .NET, which de-emphasizes languages to the point
that .NET itself IS simply a huge library, with facilities to make it
easy to use that library from any (or all) of a large and growing
collection of languages.

Of course, if you want to discuss slim languages, there's always
Smalltalk -- the language itself is absolutely puny, providing little
more than the ability to send messsages to objects, and receive back
results. Everything else is in the standard library, even such basics
as creating an object. This means the language needs a fairly large,
pre-existing standard library to be able to do anything at all.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Ioannis Vranos]

Jerry Coffin wrote:

The next obvious step is .NET, which de-emphasizes languages to the point
that .NET itself IS simply a huge library, with facilities to make it
easy to use that library from any (or all) of a large and growing
collection of languages.

More precisely, it is a CLI compliant VM environment which provides a
fairly large, high-level, Windows-oriented API which is common for all
languages.
However C++/CLI design ideals, are not only C++ to be used for
application programming as a first class citizen CLI (.NET) citizen, but
*also* for .NET library writing (managed dlls).
With C++/CLI and VC++ 2005, C++ becomes the systems programming language
of CLI (and .NET).
You may take a look at these:

http://msdn.microsoft.com/msdnmag/is...s/default.aspx

http://pluralsight.com/blogs/hsutter...0/05/2672.aspx

http://blogs.msdn.com/branbray/archi.../07/51007.aspx

http://www.accu.org/conference/prese...keynote%29.pdf
And a page of mine:

http://www23.brinkster.com/noicys/cppcli.htm

With C++/CLI, C++ has two worlds: The unmanaged world and the managed world.

In the managed world every CLI (.NET) feature is provided separately
from the unmanaged world features.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ed Falis]

On 13 Mar 2005 10:41:16 -0800, Jerry Coffin <jc*****@taeus.com> wrote:

Ada certainly provides facilities useful for writing libraries, but at
least to me seems to fall into the former group -- it works well for
writing code directly, but attempting to write good libraries in it
tends to be frustrating.

Interesting way of thinking about things. But for writing libraries, I
tend to prefer Ada and Eiffel (in that order). I don't really see what
leads to the frustration you talk about above - wouldn't mind hearing your
opinions about that.
Admittedly, creating a library written in either of these two languages
for use by other languages requires some special steps in packaging, but
they can be easily automated. Java, of course, requires anything written
in other languages to be specially packaged for it to be a client (perhaps
excepting components accessible via RMI or another component model). And
most component models require special packaging anyway.

- Ed

[Greg Comeau]

In article <19*****************@linux1.krischik.com>,
Martin Krischik <ma****@krischik.com> wrote:

Greg Comeau wrote:

In article <d1**********@sparta.btinternet.com>,
Martin Dowie <ma**********@btopenworld.com> wrote:

Greg Comeau wrote:
In article <14****************@linux1.krischik.com>,
Martin Krischik <ma****@krischik.com> wrote:And they havn't got 100% compliance - as the Ada compiler vendors
>have. And they can indedd claim that - Ada has the ACATS test -
>pass the test you are 100% compliant - fail the thest and (almost)
>no customer will consider your offer.

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.

The latest (I believe) is dated 2002 but will certainly be getting
updated to test Ada2005. See http://www.ada-auth.org/acats.html
Ok.

All compiler vendors claim some level of conformance

In what ways? This sounds like a different statement
than I thought others were saying/implying.

The Ada standart consists of the core language and optional features like
real-time system and distributed systems.

and some publish their results.

Again, seems a different statement.

You might want to read the first chapter of http://www.ada-auth.org. Usualy
the test is done by third part laboratories and then the vendor publish
"pass" for there major releases - but they might not publish for
intermediate releases :-( .

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.
Also: The test is OpenSource and it is even part the gcc source tree - so if
you have the gcc sources handy you can just run the test yourself.
Also, all compiler vendors will have a large number of
suplimentary tests of there own. These tend to include
propriatory code from customers, so usually aren't published.

I'm sure.

I'm also sure this is all workable, and to work well.
As I'm sure it's not the only way to do it (not saying
you said it was, just adding to the table).

The important point that it puts more pressure on the vendors as most
customers won't consider a compiler which won't pass the test.

I not convinced it puts "more pressure." I'm sure it puts some
pressure but "different pressure".

In the C++ world, customers do consider compilers which won't pass.
And it's no secret that this is the case, even w/o all the specifics.
(And I don't think this disses standardization efforts.)

As just one counter-example, and I've leaving out many many details,
but MS was not keeping up, and customer pressure came even w/o
"official tests", and they reacted, to their credit. So the
official tests need not be a requirement and one can get similar
end results through alternative means. No one way is perfect.
--
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*******@SpamCop.net (Larry Kilgallen) writes:

In article <wc*************@shell01.TheWorld.com>, Robert A Duff <bo*****@shell01.TheWorld.com> writes:

Ki*******@SpamCop.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.

Yes, I just said Pascal had that.

Oh, sorry, I must have thought you said "...in addition to what Pascal
has..." or something. My bad.

Anyway, nested functions are really nested in any useful sense if you
can't do uplevel addressing, right?

- Bob

[dave]

Ioannis Vranos wrote:

Jerry Coffin wrote:

The next obvious step is .NET, which de-emphasizes languages to the
point
that .NET itself IS simply a huge library, with facilities to make it
easy to use that library from any (or all) of a large and growing
collection of languages.

More precisely, it is a CLI compliant VM environment which provides a
fairly large, high-level, Windows-oriented API which is common for all
languages.
However C++/CLI design ideals, are not only C++ to be used for
application programming as a first class citizen CLI (.NET) citizen, but
*also* for .NET library writing (managed dlls).
With C++/CLI and VC++ 2005, C++ becomes the systems programming language
of CLI (and .NET).
You may take a look at these:

http://msdn.microsoft.com/msdnmag/is...s/default.aspx

http://pluralsight.com/blogs/hsutter...0/05/2672.aspx

http://blogs.msdn.com/branbray/archi.../07/51007.aspx

http://www.accu.org/conference/prese...keynote%29.pdf

And a page of mine:

http://www23.brinkster.com/noicys/cppcli.htm

With C++/CLI, C++ has two worlds: The unmanaged world and the managed
world.

In the managed world every CLI (.NET) feature is provided separately
from the unmanaged world features.

ADA.net? Surely not!!

[Robert A Duff]

co****@panix.com (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...

The ACATS has been around since the 1980's (although in those days it
was called ACVC; it got renamed ACATS around the time Ada 95 became an
ISO standard). It gets updated from time to time, as new language
revisions come out, and as the language committee issues rulings about
some fine points of the language.

As far as I know, all Ada compiler vendors take it seriously, and ensure
that their compilers pass 100% of the test suite. My company (Sofcheck,
Inc.) runs the ACATS every night, so we notice any regressions quickly.
We don't normally release a compiler that doesn't pass. I believe
AdaCore (the folks who produce the gcc version of Ada (GNAT)) do the
same.

As I said elsewhere, passing 100% of the ACATS, or 100% of any other
test suite, does not guarantee the absense of bugs (obviously).
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.)

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
unenforceable. Nobody's stopping anybody from producing a compiler for
Ada-except-some-diffs, or C++-except-some-diffs, for that matter.

- Bob

[Ed Falis]

On 13 Mar 2005 19:31:47 -0500, Robert A Duff
<bo*****@shell01.TheWorld.com> wrote:

As far as I know, all Ada compiler vendors take it seriously, and ensure
that their compilers pass 100% of the test suite. My company (Sofcheck,
Inc.) runs the ACATS every night, so we notice any regressions quickly.
We don't normally release a compiler that doesn't pass. I believe
AdaCore (the folks who produce the gcc version of Ada (GNAT)) do the
same.
Yes, we do.
As I said elsewhere, passing 100% of the ACATS, or 100% of any other
test suite, does not guarantee the absense of bugs (obviously).

Agree wholeheartedly.

- Ed

[Jeff C]

dave wrote:

ADA.net? Surely not!!

Umm...Yes
http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html

[Ioannis Vranos]

Robert A Duff wrote:

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

Here is one that major vendors use:

http://www.plumhall.com/ste.html
They are also preparing one for C++/CLI if I recall correctly.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

Here is one that major vendors use:

http://www.plumhall.com/ste.html

and

http://www.plumhall.com/libste.html

They are also preparing one for C++/CLI if I recall correctly.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[dave]

Jeff C wrote:

dave wrote:

ADA.net? Surely not!!

Umm...Yes
http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html

Well I never! Gore blimi! You what! and, well... er... yes.

If I had not seen it with my own eyes...

Nme. God Bless.

[dave]

dave wrote:

Jeff C wrote:

dave wrote:

ADA.net? Surely not!!

Umm...Yes
http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html

Well I never! Gore blimi! You what! and, well... er... yes.

If I had not seen it with my own eyes...

Nme. God Bless.

After thought:

Microsoft + CLI == Not Mission Safe

Microsoft + CLI + ADA == Bad for ADA

[Jean-Pierre Rosen]

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.

--
---------------------------------------------------------
J-P. Rosen (ro***@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

[Ioannis Vranos]

Jeff C wrote:

Umm...Yes
http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html

Unfortunately this does not load in here, so I viewed it through
google's cache. Also the ftp site does not work.
Perhaps they do not allow connections from outside the US so as to
protect the precious .NET-enabled Ada. :-)
In any case, I suspect this will be fine to create .NET applications,
however I suspect that it cannot produce 100% verifiable .NET code (the
equivalent of VC++ 2005 /clr:safe), that is 100% managed code.
That is, it must be something like VC++ 2003 for C++.
In addition, I suspect it does not provide any designer support (RAD)...

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Dr. Adrian Wrigley]

On Sat, 12 Mar 2005 09:42:26 +0100, Georg Bauhaus wrote:

Falk Tannhäuser wrote:

Dr. Adrian Wrigley wrote:

But what of features not present in either?

[...]

associative arrays (from Perl)

Wouldn't that be std::map in C++?

and in Ada 2005,

Ada.Containers.Hashed_Maps and Ada.Containers.Hashed_Maps

I have probably missed a trick in the C++, but I couldn't get
std::map code to compile (except in the trivial cases):

#include <map>

struct compoundindex {
int a, b, c;
};

int main()
{
std::map<compoundindex, float> hash;
compoundindex fred = { 1, 2, 4 };

hash[fred] = 0.123;
}

cpptest.cpp: In function `int main()':
cpptest.cpp:14: error: `main()::compoundindex' uses local type
`main()::compoundindex'
(8 more lines of errors here!)

(what is the simplest C++ code to get this intent?)
--
The Ada associative arrays from the new draft standard
are specified as something like:

generic
type Key_Type is private;
type Element_Type is private;
with function Hash (Key : Key_Type)
return Hash_Type is <>;
with function Is_Equal_Key (Left, Right : Key_Type)
return Boolean is "=";
with function "=" (Left, Right : Element_Type)
return Boolean is <>;
package Ada.Containers.Hashed_Maps is...
Which clearly won't work unless you can find the three
function generic parameters. I don't see how this can be
used easily in a generic context.

I don't think I am being *that* unreasonable in asking for arrays
indexed by arbitrary types, without jumping through hoops :)
--
Adrian

[Dr. Adrian Wrigley]

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

Robert A Duff wrote:

Ki*******@SpamCop.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!)
--
Adrian

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

#include <map>

struct compoundindex {
int a, b, c;
};

inline bool operator <(const compoundindex &a, const compoundindex &b)
{
return (a.a<b.a && a.b<b.b && a.c<b.c)? true: false;
}

int main()
{
std::map<compoundindex, float> hash;
compoundindex fred = { 1, 2, 4 };

hash[fred] = 0.123;
}

As a rule of thumb remember that most standard containers and algorithms
require the presence of operator <.
From a design perspective, in the example above, it is better to make
operator< a member of the struct. I made it a global function, in case
you want a POD struct.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Peter Koch Larsen]

"Dr. Adrian Wrigley" <am**@linuxchip.demon.co.uk.uk.uk> skrev i en
meddelelse
news:pa****************************@linuxchip.demo n.co.uk.uk.uk...

On Sat, 12 Mar 2005 09:42:26 +0100, Georg Bauhaus wrote:

Falk Tannhäuser wrote:

Dr. Adrian Wrigley wrote:

But what of features not present in either?

[...]

associative arrays (from Perl)

Wouldn't that be std::map in C++?
and in Ada 2005,

Ada.Containers.Hashed_Maps and Ada.Containers.Hashed_Maps

I have probably missed a trick in the C++, but I couldn't get
std::map code to compile (except in the trivial cases):

#include <map>

struct compoundindex {
int a, b, c;
};

int main()
{
std::map<compoundindex, float> hash;
compoundindex fred = { 1, 2, 4 };

hash[fred] = 0.123;

First off, std::map is not hash-based. It is a sorted container. Now in
order to use this, you need a comparing function. It can be the "standard"
ordering function for your key or it can be a user specified function.
}

cpptest.cpp: In function `int main()':
cpptest.cpp:14: error: `main()::compoundindex' uses local type
`main()::compoundindex'
(8 more lines of errors here!)
You must have snipped the most interesting errormessage.
(what is the simplest C++ code to get this intent?)
What you need here is a comparator:

bool operator<(compoundindex const& lhs,compoundindex const& rhs)
{
.....
}

And the map should work. --
The Ada associative arrays from the new draft standard
are specified as something like:

generic
type Key_Type is private;
type Element_Type is private;
with function Hash (Key : Key_Type)
return Hash_Type is <>;
with function Is_Equal_Key (Left, Right : Key_Type)
return Boolean is "=";
with function "=" (Left, Right : Element_Type)
return Boolean is <>;
package Ada.Containers.Hashed_Maps is...
Which clearly won't work unless you can find the three
function generic parameters. I don't see how this can be
used easily in a generic context.

I don't think I am being *that* unreasonable in asking for arrays
indexed by arbitrary types, without jumping through hoops :)
But I do! How can you index without at least knowing if two values are
different or the same?
The C++ standard will have a hash-based container later. Those interested in
having one can download one from e.g. boost (I believe this container also
to be implemented by boost and prbably several others).
--
Adrian

/Peter

[Falk Tannhäuser]

Dr. Adrian Wrigley wrote:

I have probably missed a trick in the C++, but I couldn't get
std::map code to compile (except in the trivial cases):

#include <map>

struct compoundindex {
int a, b, c;
};

int main()
{
std::map<compoundindex, float> hash;
compoundindex fred = { 1, 2, 4 };

hash[fred] = 0.123;
}

C++ associative containers (map, set, multimap, multiset) require
a "strict weak ordering" for their key types. In the present case,
it is enough to define the following 'operator<' to induce a total
ordering:

bool operator<(compoundindex const& x, compoundindex const& y)
{
if(x.a < y.a) return true;
if(x.a == y.a)
{
if(x.b < y.b) return true;
if(x.b == y.b)
return x.c < y.c;
}
return false;
}

Alternatively, if there is no natural definition for a general-purpose
operator< for the key type in question, it is possible to create a
comparison functor and to instantiate the container with it as
supplementary template parameter.
In either case, the container implementation uses the order to store its
elements in a balanced tree, so that element access becomes possible
with logarithmic complexity regarding to the number of elements currently
in the container.

Hash-based associative containers (guaranteing constant-time access as
long as there are no key collisions) are not (yet) provided by the
standard library but are widely available through third party / extension
libraries.

Falk

[Larry Kilgallen]

In article <wc*************@shell01.TheWorld.com>, Robert A Duff <bo*****@shell01.TheWorld.com> writes:

Ki*******@SpamCop.net (Larry Kilgallen) writes:

In article <wc*************@shell01.TheWorld.com>, Robert A Duff <bo*****@shell01.TheWorld.com> writes:

> Ki*******@SpamCop.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.

Yes, I just said Pascal had that.

Oh, sorry, I must have thought you said "...in addition to what Pascal
has..." or something. My bad.

Anyway, nested functions are really nested in any useful sense if you
can't do uplevel addressing, right?

I much prefer that capability, but in Bliss (which lacks uplevel addressing)
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 :-)

[Larry Kilgallen]

In article <opsnlu5k0q5afhvo@localhost>, "Ed Falis" <fa***@verizon.net> writes:

On 13 Mar 2005 19:31:47 -0500, Robert A Duff
<bo*****@shell01.TheWorld.com> wrote:

As far as I know, all Ada compiler vendors take it seriously, and ensure
that their compilers pass 100% of the test suite. My company (Sofcheck,
Inc.) runs the ACATS every night, so we notice any regressions quickly.
We don't normally release a compiler that doesn't pass. I believe
AdaCore (the folks who produce the gcc version of Ada (GNAT)) do the
same.

Yes, we do.

As I said elsewhere, passing 100% of the ACATS, or 100% of any other
test suite, does not guarantee the absense of bugs (obviously).

Agree wholeheartedly.

But it is reassuring to know that a particular compiler does at least
some things correctly.

[Larry Kilgallen]

In article <pa****************************@linuxchip.demon.co .uk.uk.uk>, "Dr. Adrian Wrigley" <am**@linuxchip.demon.co.uk.uk.uk> writes:

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

Robert A Duff wrote:

Ki*******@SpamCop.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.

But what if you actually need uplevel addressing ?

Why would one presume that users of uplevel addressing actually need
thread-private storage ? Thread-private storage would give just
a single instance per thread, not multiple nested instances per
thread.
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?

[Dr. Adrian Wrigley]

On Mon, 14 Mar 2005 17:06:10 +0100, Falk Tannhäuser wrote:

Alternatively, if there is no natural definition for a general-purpose
operator< for the key type in question, it is possible to create a
comparison functor and to instantiate the container with it as
supplementary template parameter.

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. If the necessary functions are
not passed in and built up, you can't instantiate the map/hash.
This means that you can't write an implementation of a template/generic
function using a map/hash without changing some/all the implementations
and interfaces up the instantiation tree (am I right?). Obviously this
may not be possible, for example in large a multi-team or multi
language project. If you changed from a map to a hash, you'd have
to change all the interfaces to pass the hashing function instead
or as well as the comparison operator.

In Ada, a private (nonlimited) generic formal type guarantees
an equality operation and assignment is defined for the type.
These are the only logical requirements for an associative array.
I guess an efficient hash/map library could be written for
private nonlimited generic formals, but neither std::map nor
hashed maps meet this less restrictive requirement.

Put another way, neither language has minimally restrictive
associative arrays in their (or their standard library) specification.
--
Adrian

[jtg]

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?

I had the same problem several years ago.
I was learning Ada from tutorials (www.adahome.com) and online
articles. They were nice and I could get the ideas quickly, but
they were rather shallow and I just could not find answers to
many questions.

After buying one poor book (just the only I could find in local
bookstores) I decided to search for a good book in online bookstores.
I chose "Ada as a second language" by Norman Cohen and I am very glad
with it. All the questions that bothered me (some for months) were
answered in no time. AFAIR always when I needed to know something
about Ada I could find it in this book (well, one exception:
I could not find any information about preprocessor, but some
Ada programmers claim you don't need preprocessor in Ada).

As the title suggests, the book assumes that the reader is already
a skilled programmer :-)
In the book there are many comparisons to C, C++ and some other
languages. If an Ada feature is similar to something in C or C++,
the book mentions it to help pick the idea. If there are differences,
the book mentions them too, to help avoid potential pitfalls
or correct "bad habits", i.e. ways which are natural in one
language but are not the right way to do sth in Ada. So I think
the book would be as useful for you as it was for me.

Is it difficult to move from C/C++ to Ada? Maybe I can tell
you what you may expect (from my own experience only).
When you write in Ada, it is much, much easier to get bugless
program once you manage to compile it (of course if you make
use of Ada features). However, trying to compile an Ada code may be
sometimes very, very frustrating, when the compiler complains
about sth, you look into the code and cannot find out what a strange
rule you are breaking this time in this particular place.

And in Ada you must write a lot more.
You must declare everything, you must be explicit, you must obey
the rules which sometimes seem stupid.
And you must forget about these handy i++, --j, i+=a etc.

[Ioannis Vranos]

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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Dr. Adrian Wrigley]

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. 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!
(should I give a code example?)
--
Adrian

[kevin cline]

ad******@sbcglobal.net wrote:

Consider a military commmand and control system, a
complex system with a lot
of requirementss built in. Now, think of this
system in terms of its size: 4.5 million
lines of source code.

But not all lines of source code are created equally. Written in a
more expressive language the application might be only half that size,
or most likely even less.

[kevin cline]

Martin Krischik wrote:

Shure it is true: The C++ ISO standard has ruffly 200 pages more then the Ada ISO standard. The C standard is a few pages shorter - but C hasn't got object orientation, concurency, real time and distributed system included.

No surprise there. The C++ standard covers the C++ standard library.
But prove me wrong and show me any successful slim language - which has not become fat (either by language or by build in library) withing 10 years of becomming successfull.

Personally I prefer slimmer languages and fatter libraries whenever
possible.

[Dmitry A. Kazakov]

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

It can be formulated in two words: "contract model" is what C++ templates
lack.

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

[Georg Bauhaus]

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.

I think this description is o.K. for Ada, but perhaps not
for C++. E.g. you can place the following in three different
files (modules), somewhat like in Ada, and you don't have
to write the < into the module containing the compared type.

// 1

#include "comp.h"
#include <map>

bool operator< (V a, V b) { return a.val() < b.val(); }

int main()
{
std::map<V, float> m;
V key1, key2 = V(3);

m[key1] = 1.0;
m[key2] = 1.0;

return 0;
}

// 2

class V {
int v;
public:
V() : v(0) {}
V(int val) : v(val) {}
int val() const;
};

// 3

#include "comp.h"

int V::val() const {
return v;
}

Georg

[Ioannis Vranos]

Dr. Adrian Wrigley wrote:

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.

Yes. However if you later convert to a hash container, it can remain
around unused in the particular container.

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!
(should I give a code example?)

Yes, also operator< is used to all containers and algorithms where a
comparison takes place, like sorting algorithms (std::sort,
std::stable_sort, etc).
I can not understand how this could be avoided for such operations and
containers, since a comparison is required.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Robert A Duff]

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

Robert A Duff wrote:

Ki*******@SpamCop.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.

I beg to differ. Uplevel references can be implemented as efficiently
as parameter passing (which is what you normally do in C-family
languages as a substitute). And it can cost nothing when not used.
It can also cost nothing when the procedures involved can be inlined
(which is a very common case -- the reason I'm writing a nested procedure
is usually so I can pass it to an iterator, and both the iterator and
the nested procedure are usually small enough to deserve inlining).

(I'm not a big fan of displays, by the way.)
If you need thread-private storage, there are *much* cheaper solutions.

This seems like a nonsequitor -- thread-private storage and uplevel
references are different things, with different (though somewhat
related) purposes. C and C++ have neither, which can make using thread
packages painful, though gcc supports uplevel references (for both C and
Ada, and I think C++ also).

And having implemented both, I'd say thread-private storage is
generally more expensive than uplevel references. What's your
much cheaper solution?

- Bob

[Ioannis Vranos]

kevin cline wrote:

Personally I prefer slimmer languages and fatter libraries whenever
possible.

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

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

It can be formulated in two words: "contract model" is what C++ templates
lack.

I think "explicit contract model" is slightly better, and perhaps
you can say something about the closure that the compiler needs
to find out whether a contract is fulfilled (Can_Copy etc.)?
Georg

[Greg Comeau]

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

co****@panix.com (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
unenforceable. 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*******@SpamCop.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<interval, 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.fr> 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()(const Stuff& lhs, const Stuff& rhs) { ... }
}

std::set<Stuff, compareStuff> zeds;

[Robert A Duff]

"Dmitry A. Kazakov" <ma*****@dmitry-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*******@SpamCop.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.com (Greg Comeau) writes:

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

co****@panix.com (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
unenforceable. 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