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

[Chad R. Meiners]

The question is the degree to which that situation holds here. Thus

far, you've provided essentially nothing in the way of independent
corroboration of any of your statements at all.

So how does one provide independent corroboration over usenet? If such
a method exists, is the method's cost reasonable? Is there an ISO
standardize method?

 

[Chad R. Meiners]

quote 1

(e.g. "Although the Ada
tool vendors finance it through the ARA, the ACAA's real boss is the
ISO" (from http://www.adaic.com/compilers/acaa.html).

-and-

quote 2

The ISO has this to say:

When I read your post I recognized the the phrase "the ISO" in quote
one and two have distinct meanings. That is they don't refer to the
same thing. However, the rest of your post seems to rely on them
meaning the same thing. How do you account for this?

 

[Randy Brukardt]

....

The question is the degree to which that situation holds here. Thus
far, you've provided essentially nothing in the way of independent
corroboration of any of your statements at all. You make a statement
here, and then offer your own statement on your own web site as the
"corroborating evidence."

I can't imagine what sort of "independent corroboration" would satisfy you
(or why it matters, for that matter). I've already pointed you at the ISO
standard and the WG9 web site. Pretty much all of the other material on
testing was written by me. There's nothing sinister about that: I'm the only
one that is paid here, and thus I end up writing it. Of course, the
volunteer review board reviewed and approved that material. But even if that
was done publically, it wouldn't satisfy you, because *I* the webmaster of
the site and therefore would have probably formatted and posted the
material. Our budget isn't large enough to have multiple people doing
overlapping jobs just to prove some sort of independence.

Our way of proving relability is to conduct the entire process in public.
Thus, the procedures, test reports, and test suite are all publically
available. And I insist that these have enough information in them so that
any member of the public can reproduce the testing. (This isn't like the
destructive testing of ICs that only a few specialists can run -- anyone who
knows how to run a compiler can run the tests on it; and they had better get
the same results.) That means that any fault in the process can be exposed,
and that should provide a strong incentive to avoid bending the rules.

If that is not good enough for you, then there is nothing else I can say.
Personally, I would trust an open process over one that is not open, not
matter how independent the latter is. After all, the supposedly independent
government run process was cheated several times; because the reports
weren't readily available to the public, there was little chance that those
would be detected.

Randy.

 

[Jerry Coffin]

Chad R. Meiners wrote:

[ ... ]

So how does one provide independent corroboration over usenet?

Usually by pointing to a reasonably recognizable reference. Given that
Usenet is carried primarily over the Internet, something like the
address of a recognizable web site is an obvious possibility.

If such a method exists, is the method's cost reasonable?

It's usually free.

Is there an ISO standardize method?

I'm not sure what you're asking here -- if you're asking whether the
ISO has methods for standardizing things, of course they do.

 

[Jerry Coffin]

quote 1

-and-

quote 2

When I read your post I recognized the the phrase "the ISO" in quote
one and two have distinct meanings. That is they don't refer to the
same thing. However, the rest of your post seems to rely on them
meaning the same thing. How do you account for this?

Is this a troll? What in the world do you think "the ISO" could refer
to other than the ISO?

 

[Jerry Coffin]

Robert A Duff wrote:

[ ... ]

Sorry, I don't know how to say it politely, but this argument (on
both sides) is patently ridiculous. For one thing, neither C++ nor
Ada 95 existed at the time the Arpanet was created.

Previously noted.

For another thing, Ada has never been "a language the DoD considered
its own" -- the design has always been entirely open.
For goodness sakes, they even chose a
foreigner (Jean Ichbiah, who is French) to do the original 1983
language design!

Hmm...so your position is that the DoD _couldn't_ feel posessive about
it because at least part of that would be irrational?

Perhaps we should start over from the beginning. Hi. Welcome to our
planet. We like to call it "earth." We call ourselves "people".
Rationality in individuals is rare and in large groups, nonexistent.
Unfortunately, even though you seem to speak (or at least type) English
just like the TV shows said you would, your thinking is appearently so
different from ours that we'll probably never be able to truly
communicate.

 

[Jerry Coffin]

Wes Groleau wrote:

[ ... ]

Interesting. Ada is bad because you _think_ it won't let you do what
you want to do.

First of all, I've never said Ada was bad -- at worst, I've said that I
found some things about it frustrating. Second, my opinions are based
on use, not just what I think might be true about it. Finally, I've
openly admitted that some (pehaps all) of my opinions may be obsolete
since my experience predates Ada 95.

But it would be better if it prevented other people
from doing something you think they shouldn't do.

It's been close to 10 years now that Java has had its multi-level
break, and in that time I'm not at all certain I've seen even _one_
instance of its use that wouldn't have been better off without it.

In the end, designing a (good) programming language requires a lot of
judgement calls, not simply applying some simplistic rule like "allow
everything". A theoretically ideal programming language would allow
everything that was intended and desired, but stop everything that
wasn't.

Real languages deal in compromises -- one is that permitting more of
what people want to do also generally allows more things they didn't
really want to do.

I think this "feature" has an even greater cost though. While most
people recognize that the undisguised goto is something to generally
avoid, many (especially those too young to have dealt with FORTRAN II
computed gotos) rarely consciously realize that a break (of any sort)
is simply a restricted form of a goto -- and the less restricted it is,
the more it's just a goto by a different name.

The result is that when people are faced with using a goto to exit from
a deeply nested loop, they usually have second thoughts -- and with a
little more thought, realize that the code can be re-structured to
eliminate the real problem that led them to want to do that in the
first place.

OTOH, when that goto is disguised as a "multi-level break", it appears
(at least to me) that they're much more willing to just use the
goto^H^H^H^Hmulti-level break instead of fixing the code.

In fairness, the multi-level goto is marginally more justifiable in
Java than in Ada -- Java copied all of C's biggest mistakes, including
its screwed up switch/case statement. It's quite often useful to have a
switch statement in a loop, and exit the loop as one of the legs of the
switch -- but the screwed-up switch makes this a multi-level break.

Regardless of other shortcomings I might see in its design, Ada did get
its case statement right, so a single-level break suffices for this
situation.

 

[Ioannis Vranos]

In fairness, the multi-level goto is marginally more justifiable in
Java than in Ada -- Java copied all of C's biggest mistakes, including
its screwed up switch/case statement. It's quite often useful to have a
switch statement in a loop, and exit the loop as one of the legs of the
switch -- but the screwed-up switch makes this a multi-level break.

I think that wanting to break a loop from inside a case block is very
rare, after all one places (should place) minimal code in switch cases.


On the other hand, although the designers of C#/CLI claimed their switch
implementation to be better than C++ (as with every other language
detail, they were very excited with C#/CLI in the beginning, they viewed
it as a cure-all kind of thing, now they have switched back to C++ as
the systems programming language of .NET), I think it is inferior. It
goes with something like this if you want to use more than one cases:


switch(value)
{
case 1:
{
// ...

goto case 2;
}

case 2:
{
// ...
}


case 3:
{
// ...
}
}


with implicit breaks among cases. Personally I do not like this goto stuff.

 

[Chad R. Meiners]

the ISO = the ISO standard for Ada
the ISO = the Internatioal Standard Organization

 

[Guest]

The mindset that embraces Ada simply would never have designed things
that way. Heck, I'm clearly on the C++ side of the fence, and I stil
find many of them at least mildly distasteful. Had they been designed
by Ada programmers, the hackish character would be gone. Instead, the
system would be designed to operate in harmony as a coordinated system.

Possibly. However, I have seen more than enough "hacked" Ada to wonder
whether, in the hands of the larger community, the unruly would still run amuck,
even with Ada as their language. Although the default for most constructs in
Ada tends toward the notion of "safe," there are lots of ways to "relax" the
language's emphasis on safety. I recall that when I first learned Ada, I used
to first read Appendix F of any compiler manual so I could find ways to get
down to the machine level, do workarounds, and migrate back to my original
assembler programmer roots. It took me quite a while to finally understand
the value of limited types, the strict model that separates scope and
visibility,
and other important [engineering] ideas unique to Ada.

As to C and C++, the rules are much more relaxed at the outset than they
are in Ada. It is difficult to take a language that is not type-safe and get
programmers to make it type-safe than it is to take a language that is
type-safe and selectively relax the rules - something we do routinely
in Ada.

Richard Riehle

 

[Guest]

There are compliance tests for C++ too.

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

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

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

Richard Riehle

 

[Guest]

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

Not Eiffel?

Richard Riehle

 

[Jerry Coffin]

Not Eiffel?

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

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

 

[Yermat]

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

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

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

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

 

[Robert A Duff]

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

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

I think ECMA is working on an Eiffel standard.

See:

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

- Bob

 

[Robert A Duff]

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

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

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

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

Well, we have alloca() for this

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

- Bob

 

[Robert A Duff]

So the example becomes:

#include <boost/integer.hpp>


int main()
{
using namespace boost;

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

my_var= 9;
}


Indeed.

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

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

- Bob

 

[Paul Dietz]

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

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

Paul

 

[Ioannis Vranos]

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

OK, however as I have mentioned before, one can also provide this type
of guarantees in C++, without any run-time checks:


#include <vector>


int main()
{
using namespace std;

vector<int> intVector;

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





#include <vector>


int main()
{
using namespace std;

vector<int> intVector;

for(vector<int>::const_iterator p= intVector.begin();
p!=intVector.end(); ++p)
;// ...
}




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

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

// ...

vector<int>someArray(10, 1);

// ...

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



etc.

 

[Guest]

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

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

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

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

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

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

Richard Riehle