Re: Bug story

Re: Bug story

[Fergus Henderson]

"Samuel T. Harris" <sam_harris@hso.link.com> writes:

>Dave Sparks wrote:
>> 
>> Let me try to summarise the argument to date: it was asserted that
>> a code fragment like { A + 1; } (where the value of the expression
>> is discarded) can be optimised out because the code has no effect;

And indeed this is true, unless `A' was declared `volatile'.
(I presume by the syntax you are talking about C and/or C++.)

>A similar problem involves programming EGA cards.

And again, the solution is similar -- declare the video memory `volatile'.

>Personally,
>this was a common problem for me in the 80's as Ada compilers
>on PC's got better and better.

The solution in Ada is basically the same as in C/C++, with slightly
different syntax: `pragma Volatile' rather than `volatile'.

Well, that's true in Ada 95, at least.  I don't know off-hand
whether `pragma Volatile' was present in Ada 83.  Perhaps someone
from comp.lang.ada can tell us.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Why C++ is successful

[Rakesh Malhotra]

Dave Martin wrote:
> [lots of stuff deleted]
 
> Throughout all this, I also heard about modula-2 and ada.  Ada was
> specifically not object oriented, everyone seemed to hate it, and it
> was being mandated by the federal government, and I'd heard several
> horror stories from people who had been forced to write in ada.  Also,
> there was the holier-than-thou attitude that ada proponents seemed to
> have. This combination of factors did not make ada look good (esp the
> mandate and the lack of O-O).  I could understand the desire behind
> ada, but it seemed like the implementation was just not good.  As for
> modula-2, I just never got into it.
> [deleted stuff]

Just a short response on the above topic - just to get the facts
straight.  The 2nd revision of the Ada standard was released in 1995 and
in its current form Ada is fully object-oriented, including dynamic
dispatching and inheritance.

Personally, I work in the commercial industry in the US where Ada is not
mandated (never has been) and we use Ada very successfully and intend to
continue doing so.  The reasons for us using it are very straight
forward - while no current language can force good design or good
programming practices, languages like Ada or Eiffel certainly encourage
these good design/programming practices.  We use Ada for its support of
sound software engineering principles resulting in software that is
highly reliable, maintainable, readable, portable etc, without expending
the kinds of effort needed with other languages.

A lot of the "holier-than-thou attitude" 's, if they ever did indeed
exist, are certainly not there anymore.  Most people that I have bumped
into who use Ada are very much down to earth folks who are just trying
to get a job done well.  Also, while you are very correct regarding
Ada83 compiler implementations ("horror stories")  , today, there are
very good Ada compilers available, including for free (www.gnat.com),
and most vendors have brought prices down to the same level as for C,
C++ compilers.  

The biggest problem that Ada suffers from today is an image one.  Lots
of people perceive it as being poor,slow,old technology etc and hate it
without ever having written a line of code in it.  As someone who has
used Ada, C, C++, etc for many years, I would just like to say that that
is all it is - image - and does not really reflect reality.  

--
Rakesh

Re: Why C++ is successful

[Larry Elmore]

Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>"Pat Rogers" <progers@acm.org> wrote:
>
>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>>>Pat Rogers wrote:
>>>>
>>>> That's why I'm learning Java now, and Eiffel and C++ in the past.  They
all
>>>> contribute something to make one a better developer.  I need to take
another
>>>> look at Fortran, because it sure isn't the Fortran IV I used in the old
>>>> days!
>>>
>>>  You'll be happy you did.
>>>  Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>>their niche.
>>
>>
>>Since you mention it, what would you say is Fortran's niche that the
language is
>>unbeatable in filling?  (Serious request for opinion, not yet another
language
>>flame war ignition.)
>
>Mathematical calculations.  The science, engineering, business, and
>other groups requiring large amounts of efficient math processing have
>overwhelmingly adopted Fortran for decades.

But isn't this largely due to a combination of inertia, legacy code,
existing libraries plus compilers that are very, very good at optimizing
that kind of code (they've certainly had enough time to get them working
right!), rather than anything to do with the language itself?

Larry

Re: Why C++ is successful

[Jay Martin]

Pat Rogers wrote:
> 
> Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
> >Pat Rogers wrote:
> >>
> >> [Big Snip]
> >>
> >> That's why I'm learning Java now, and Eiffel and C++ in the past.  They all
> >> contribute something to make one a better developer.  I need to take another
> >> look at Fortran, because it sure isn't the Fortran IV I used in the old
> >> days!
> >>
> >
> >  You'll be happy you did.
> >  Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
> >their niche.
> 
> Since you mention it, what would you say is Fortran's niche that the language is
> unbeatable in filling?  (Serious request for opinion, not yet another language
> flame war ignition.)

I believe Fortran (i.e. High Performance Fortran) is king for
scientific array calculations on massively parallel
machines.  These compilers will take a program
that does calculations on arrays and generate code
that distributes the arrays across all the processors
and efficiently schedules data communication between
the processors.  I don't know if there is a
viable "High Performance C/C++" in the market yet.

Jay

Re: Why C++ is successful

[nabbasi]

In article <6pmmd7$5t7@gcsin3.geccs.gecm.com>, John says...

> My view now is that I would still like to learn C++, but only 
>really for interest, from what I know of Ada 95 and C++, Ada 95 certainly 
>seems to be the more understandable language and, with the increasing 
>size and complexity of software systems which require maintenance, I know 
>what I d rather maintain.
>

you might be interested in this C++ critque (sp?) :

http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html

in particular this section:

http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3/sect3/
                                                           
Nasser

Re: Why C++ is successful

[Dave Martin]

I certainly wasn't trying to attack ada and I hope it didn't come off
that way.  I was just relating the experiences that I had.  Its true
that many people use Ada and are quite happy to do so; and Ada-95 has
added a lot to the language in an O-O context.

We are surrounded by many DOD installations around here, and Ada usage
was mandated by the DOD until recently.  Many of the people I know
were upset because they were told "you will use Ada" and many
obviously biased studies were bandied about (the kind where it was
obvious that the people conducting the study were told what result to
come up with before they started the study).  I'm sure you can find
many such "studies" on just about any topic.

I personally haven't learned Ada (83/95) yet, so I hesitate to say
anything one way or the other about it, though I will admit to being
influenced by my friends occasionally on the subject.  I know many
people who hate Ada, and I know there are many others who swear by it.

I'm not sure I'll ever get around to learning Ada; Eiffel is my
current "education" project.  I just hope that people using whatever
language for some project are using them from an informed position and
choice; and not for "religious" reasons.  I know someone who refused
to move from C to C++ because of all that ickyness C++ added to C.
sigh.  I once got him to (reluctantly) admit that prototypes were a
good thing, but thats about as far as he'll go.  He also generally
hates what ANSI/ISO did to C.

Personally, for the last several years i've been trying to detect my
own hidden assumptions and biases, and nullify them.  I never want to
turn into the old dog who can't learn new tricks or becomes closed-
minded to something simply because its different.  Unfortunately I
haven't always been successful, but i'm trying.

On Tue, 28 Jul 1998 18:56:44 -0700, Rakesh Malhotra
<rakesh.malhotra@safetran.com> wrote:

[stuff about Ada's image and its good points deleted, see previous
posting]

<*> - Know Future

Re: Why C++ is successful

[John McCabe]

Just for the sake of interest, when I first started watching this 
newsgroup (comp.lang.ada) around 3.5 years ago, it was very much from the 
point of view of wanting to convince people that Ada is not worth the 
effort any more. Looking back, I found that there were a few, let�s say, 
inadequacies in Ada 83 that, in my view, let down the whole language. 
Also at the time I much preferred the C language (actually I liked Occam 
even better, but it never really caught on!), and hated the idea that I 
was being forced to use Ada against what I considered to be my better 
judgement.

My views on Ada have completely changed since then. It was pointed out by 
a number of very helpful people around here that there were reasons and 
workarounds for the �inadequacies� I mentioned, but also that some of 
them at least had been addressed in Ada 95 and so were not relevant any 
more, however the main turning point came when I got gold of the GNAT 
compiler just to write a fairly noddy program which would hopefully run 
on both a PC and Sun Workstation. Normally I would have knocked this up 
in C and spent some time debugging it. This time I decided to try Ada and 
found that once I�d managed to get the program to compile, it pretty much 
did what I had wanted (apart from a few very trivial, and very easy to 
find bugs). When I ported it across to Solaris, and recompiled with GNAT 
for Solaris, it worked first time!

This would never have happened if I�d written it in C.

As far as C++ is concerned, I spent a long time trying to persuade my 
boss to let me go on a C++ course. I never got it as there was apparently 
no need for it (despite the fact that even Ada contract software guys are 
now getting the opportunity to learn C++ in that department!! - I left 1 
year ago). My view now is that I would still like to learn C++, but only 
really for interest, from what I know of Ada 95 and C++, Ada 95 certainly 
seems to be the more understandable language and, with the increasing 
size and complexity of software systems which require maintenance, I know 
what I�d rather maintain.



-- 
Best Regards
John McCabe

=====================================================================
Not necessarily my company or service providers opinions.
=====================================================================

Re: Why C++ is successful

[Jean-Pierre Rosen]

Dave Martin a �crit dans le message <35bebe5f.95187031@netnews.msn.com>...
>I personally haven't learned Ada (83/95) yet, so I hesitate to say
>anything one way or the other about it, though I will admit to being
>influenced by my friends occasionally on the subject.  I know many
>people who hate Ada, and I know there are many others who swear by it.
>
A short comment on this from someone who has been teaching/consulting in Ada
since 1980 (no typo here!)

I too have met people who hated Ada (no need to comment on the other ones
:-). Most of the time, it was either because of 1) problems with compilers
or 2) improper training.

As far as 1) is concerned, people see the language through the compiler. If
the compiler is poor, they have a feeling that the language is poor. The
strange thing is that quite often, they refuse to change compiler, and would
rather change language instead. Fortunately, current compilers are much
better, so we can expect this reason to vanish in the future.

As for 2), "Ada is more than just another programming language". Although it
syntactically looks like an enhanced Pascal, programming in Ada requires a
different state of mind. You don't program a computer, you design an
application, the compiler is in charge of bridging the gap between your high
level description and the machine level. People who were not properly
trained often do not understand this different approach, and get very poor
results, with a feeling that strong typing "gets in the way". As Booch
pointed out: "Give a power drill to a carpenter who has never heard of
electricity, and he'll use it as a hammer. He'll bend a few nails and smash
his fingers, because a power drill make a lousy hammer".

I can tell from experience that *very often*, my students tell me a the end
of the course that the language they have discovered was completely
different from what they had heard about it...
--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Why C++ is successful

[Pat Rogers]

Dave Martin wrote in message <35bebe5f.95187031@netnews.msn.com>...
>I certainly wasn't trying to attack ada and I hope it didn't come off
>that way.  I was just relating the experiences that I had.  Its true
>that many people use Ada and are quite happy to do so; and Ada-95 has
>added a lot to the language in an O-O context.

I think it is laudable that you have said the above; your earlier post did
indeed come off (to me, anyway) as spreading uninformed and out-of-date
hearsay (not heresy :).

>We are surrounded by many DOD installations around here, and Ada usage
>was mandated by the DOD until recently.  Many of the people I know
>were upset because they were told "you will use Ada" and many
>obviously biased studies were bandied about (the kind where it was
>obvious that the people conducting the study were told what result to
>come up with before they started the study).  I'm sure you can find
>many such "studies" on just about any topic.


Ah, "the Mandate".  Imagine you work in a building that uses approximately
450 different kinds of electrical outlet.  Now imagine moving your office
equipment from one office to another; sure would be nice if all the outlets
were compatible, because the equipment can't be used in the new office.
That's the position the DoD found itself in, when they decided maybe a
standard programming languages was a good idea.  (Approximately 450
different languages and dialects of languages were in use in embedded
systems, the domain in which DoD was spending the most money.)  Too bad they
didn't follow through with what they got, because it was very good; not for
everything, but certainly for embedded systems (warts and all).

I've been involved with Ada since 1980, and have often had to convince my
DoD customers that Ada was the way to go, but they were never sorry in the
end.  For the commercial stuff, we don't have to convince anybody because it
isn't an issue.

>I personally haven't learned Ada (83/95) yet, so I hesitate to say
>anything one way or the other about it, though I will admit to being
>influenced by my friends occasionally on the subject.  I know many
>people who hate Ada, and I know there are many others who swear by it.

I'll bet the used an inferior compiler, or had poor/no training.  Anyway, if
they took the attitude of being forced to do it, how successful could they
have been?

>I'm not sure I'll ever get around to learning Ada; Eiffel is my
>current "education" project.  I just hope that people using whatever
>language for some project are using them from an informed position and
>choice; and not for "religious" reasons.  I know someone who refused
>to move from C to C++ because of all that ickyness C++ added to C.
>sigh.  I once got him to (reluctantly) admit that prototypes were a
>good thing, but thats about as far as he'll go.  He also generally
>hates what ANSI/ISO did to C.
>
>Personally, for the last several years i've been trying to detect my
>own hidden assumptions and biases, and nullify them.  I never want to
>turn into the old dog who can't learn new tricks or becomes closed-
>minded to something simply because its different.  Unfortunately I
>haven't always been successful, but i'm trying.

That's why I'm learning Java now, and Eiffel and C++ in the past.  They all
contribute something to make one a better developer.  I need to take another
look at Fortran, because it sure isn't the Fortran IV I used in the old
days!

Since the Ada model of OO is just enough different to have some advantages,
why not learn a little about Ada? The language Rationale can be downloaded
for free.  Plus there's built-in tasking, support for deterministic
real-time programming, distribution, and a host of other things you won't
see elsewhere.

-- pat

Patrick Rogers
progers@acm.org
http://www.neosoft.com/~progers

Re: Why C++ is successful

[Brian Rogoff]

On Wed, 29 Jul 1998, Pat Rogers wrote:
> Dave Martin wrote:
... snip ...
> >
> >Personally, for the last several years i've been trying to detect my
> >own hidden assumptions and biases, and nullify them.  I never want to
> >turn into the old dog who can't learn new tricks or becomes closed-
> >minded to something simply because its different.  Unfortunately I
> >haven't always been successful, but i'm trying.
> 
> That's why I'm learning Java now, and Eiffel and C++ in the past.  They all
> contribute something to make one a better developer.  I need to take another
> look at Fortran, because it sure isn't the Fortran IV I used in the old
> days!

I don't want to discourage anyone from learning new things, but IMO Java,
Ada, C++, and Eiffel are not really all that different, I'd even say they 
are pretty close in the whole space of programming languages. Why not try 
a few really different languages, like:

(1) A logic language, like Prolog or Mercury
(2) A functional language, like OCaml, Haskell, or Scheme
(3) An OO language with multimethods, like Common Lisp
(4) Any of a number of interesting other languages, like Forth, Icon, ...

This isn't meant as a disagreement with Pat Rogers. I actually like Ada 
and think it is worth knowing, just that if you want to stretch your mind 
and are not solely interested in getting a job using some particular 
language, it might be worth it to you to consider a wider range.

-- Brian

Re: Why C++ is successful

[John McCabe]

Brian Rogoff <bpr@shell5.ba.best.com> wrote:

>This isn't meant as a disagreement with Pat Rogers. I actually like Ada 
>and think it is worth knowing, just that if you want to stretch your mind 
>and are not solely interested in getting a job using some particular 
>language, it might be worth it to you to consider a wider range.

Alternatively, if you want to earn lots of money from a dead language, 
learn Occam and move to the UK as a software contractor. I've had a few 
calls about Occam jobs, there are a few legacy apps out there that can't 
move away from Occam, but I'm not prepared to risk it.

-- 
Best Regards
John McCabe

=====================================================================
Not necessarily my company or service providers opinions.
=====================================================================

Re: Why C++ is successful

[Charles Hixson]

But what Ada REALLY needs is a good garbage collection mechanism.  And
saying "Do it by hand" doesn't qualify as good!

Brian Rogoff wrote:
> 
> On Wed, 29 Jul 1998, Pat Rogers wrote:
> > Dave Martin wrote:
> ... snip ...
> > >
> > >Personally, for the last several years i've been trying to detect my
> > >own hidden assumptions and biases, and nullify them.  I never want to
> > >turn into the old dog who can't learn new tricks or becomes closed-
> > >minded to something simply because its different.  Unfortunately I
> > >haven't always been successful, but i'm trying.
> >
> > That's why I'm learning Java now, and Eiffel and C++ in the past.  They all
> > contribute something to make one a better developer.  I need to take another
> > look at Fortran, because it sure isn't the Fortran IV I used in the old
> > days!
> 
> I don't want to discourage anyone from learning new things, but IMO Java,
> Ada, C++, and Eiffel are not really all that different, I'd even say they
> are pretty close in the whole space of programming languages. Why not try
> a few really different languages, like:
> 
> (1) A logic language, like Prolog or Mercury
> (2) A functional language, like OCaml, Haskell, or Scheme
> (3) An OO language with multimethods, like Common Lisp
> (4) Any of a number of interesting other languages, like Forth, Icon, ...
> 
> This isn't meant as a disagreement with Pat Rogers. I actually like Ada
> and think it is worth knowing, just that if you want to stretch your mind
> and are not solely interested in getting a job using some particular
> language, it might be worth it to you to consider a wider range.
> 
> -- Brian

-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

Re: Why C++ is successful

[falis]

> But what Ada REALLY needs is a good garbage collection 
mechanism.  And
> saying "Do it by hand" doesn't qualify as good!
> 

For the Ada to JVM target, it comes with the JVM.

For UNIX and Windows targets, our product, ObjectAda works 
with Geodesic Systems Great Circle garbage collector - just link 
with a Great Circle object module and appropriate library.

- Ed Falis
Aonix

Re: Why C++ is successful

[Rakesh Malhotra]

Dave Martin wrote:
> 
> I certainly wasn't trying to attack ada and I hope it didn't come off
> that way.  I was just relating the experiences that I had.  Its true
[stuff deleted]

Nope, I certainly did not feel that you were attacking Ada (or any other
language, for that matter).  Your post was just about what you went
through/are going through in learning different languages.

The only reason I bothered to reply was for the benefit of those who may
have read your post and arrived at uninformed conclusions about Ada.

Incidentally, if you decide to get on the Java bandwagon, there have
been Ada to Java-byte code compilers available for some time.  These
give you the benefit of programming in Ada while being able to use all
the Java API's.

Thanks
--
Rakesh

Re: Why C++ is successful

[Tom Moran]

My son just finished his freshman college year.  Talking to his
friends who took programming courses at non-unknown colleges (eg, UC
Berkeley, etc), not one used C++.  

Re: Why C++ is successful

[Ell]

tmoran@bix.com (Tom Moran) wrote:

>My son just finished his freshman college year.  Talking to his
>friends who took programming courses at non-unknown colleges (eg, UC
>Berkeley, etc), not one used C++.  

Are his friends computer science or software engineering majors?  And
if so how far along are they in taking their major courses?  There are
probably few comp sci and sw eng majors who graduate without at least
one C++ course.

There are many college students taking general programming courses who
do not and probably should not take C++.   Non-CS/SWE majors who want
to take one or two programming courses should probably learn VB in my
opinion.

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

Re: Bug story

[Robert I. Eachus]

In article <6pcati$8l7$1@mulga.cs.mu.OZ.AU> fjh@cs.mu.oz.au (Fergus Henderson) writes:

  > The solution in Ada is basically the same as in C/C++, with slightly
  > different syntax: `pragma Volatile' rather than `volatile'.

  > Well, that's true in Ada 95, at least.  I don't know off-hand
  > whether `pragma Volatile' was present in Ada 83.  Perhaps someone
  > from comp.lang.ada can tell us.

   Most compilers provided it, but it was not a required pragma.

   Note that this is technically still the situation in Ada 95.
Pragma Volitile is only required for compilers which support the
Systems Programming Annex.  (Of course, I can't imagine a serious
Ada 95 compiler not supporting it, even if for some reason they don't
support the entire SP Annex.)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Why C++ is successful

[Tom Moran]

>Are his friends computer science or software engineering majors? 
Since they have just complete freshman year, no, they cannot yet be
majors.  But some clearly plan to be.  I would hope any CS or SE major
studies *several* substantially different  languages during his four
years.

Re: Why C++ is successful

[Ell]

tmoran@bix.com (Tom Moran) wrote:

>>Are his friends computer science or software engineering majors? 
>Since they have just complete freshman year, no, they cannot yet be
>majors.

So freshman can not have upper class friends.  That's a new one.

>But some clearly plan to be.  I would hope any CS or SE major
>studies *several* substantially different  languages during his four
>years.

So what's the point of saying they currently haven't studied C++?

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

Re: Why C++ is successful

[Pat Rogers]

Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>Pat Rogers wrote:
>>
>> [Big Snip]
>>
>> That's why I'm learning Java now, and Eiffel and C++ in the past.  They all
>> contribute something to make one a better developer.  I need to take another
>> look at Fortran, because it sure isn't the Fortran IV I used in the old
>> days!
>>
>
>  You'll be happy you did.
>  Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>their niche.


Since you mention it, what would you say is Fortran's niche that the language is
unbeatable in filling?  (Serious request for opinion, not yet another language
flame war ignition.)

Re: Why C++ is successful

[Pat Rogers]

Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>"Pat Rogers" <progers@acm.org> wrote:
>
>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...

<snip>
>>>  You'll be happy you did.
>>>  Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>>their niche.
>>
>>
>>Since you mention it, what would you say is Fortran's niche that the language
is
>>unbeatable in filling?  (Serious request for opinion, not yet another language
>>flame war ignition.)
>
>Mathematical calculations.  The science, engineering, business, and
>other groups requiring large amounts of efficient math processing have
>overwhelmingly adopted Fortran for decades.


Gee, thanks.  I didn't know that.

Sigh.  I suppose I didn't ask it well -- I meant " what is it about Fortran that
makes it unbeatable as a language for the niche *Juan Carlos* considers it to
fill?"

Re: Why C++ is successful

[Juan Carlos Gil Montoro]

Pat Rogers wrote:
> 
> [Big Snip] 
>
> That's why I'm learning Java now, and Eiffel and C++ in the past.  They all
> contribute something to make one a better developer.  I need to take another
> look at Fortran, because it sure isn't the Fortran IV I used in the old
> days!
>

  You'll be happy you did.
  Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
their niche. 

Juan Carlos---

Re: Why C++ is successful

[Ell]

"Pat Rogers" <progers@acm.org> wrote:

>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>>Pat Rogers wrote:
>>>
>>> [Big Snip]
>>>
>>> That's why I'm learning Java now, and Eiffel and C++ in the past.  They all
>>> contribute something to make one a better developer.  I need to take another
>>> look at Fortran, because it sure isn't the Fortran IV I used in the old
>>> days!
>>>
>>
>>  You'll be happy you did.
>>  Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>their niche.
>
>
>Since you mention it, what would you say is Fortran's niche that the language is
>unbeatable in filling?  (Serious request for opinion, not yet another language
>flame war ignition.)

Mathematical calculations.  The science, engineering, business, and
other groups requiring large amounts of efficient math processing have
overwhelmingly adopted Fortran for decades.

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

Re: Why C++ is successful

[Ell]

"Pat Rogers" <progers@acm.org> wrote:

>
>Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>>"Pat Rogers" <progers@acm.org> wrote:
>>
>>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>
><snip>
>>>>  You'll be happy you did.
>>>>  Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>>>their niche.
>>>
>>>
>>>Since you mention it, what would you say is Fortran's niche that the language
>is
>>>unbeatable in filling?  (Serious request for opinion, not yet another language
>>>flame war ignition.)
>>
>>Mathematical calculations.  The science, engineering, business, and
>>other groups requiring large amounts of efficient math processing have
>>overwhelmingly adopted Fortran for decades.
>
>
>Gee, thanks.  I didn't know that.

Next time don't ask.

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

Re: Why C++ is successful

[Ell]

"Pat Rogers" <progers@acm.org> wrote:

>
>Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>>"Pat Rogers" <progers@acm.org> wrote:
>>
>>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
>
><snip>
>>>>  You'll be happy you did.
>>>>  Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
>>>>their niche.
>>>
>>>
>>>Since you mention it, what would you say is Fortran's niche that the language
>is
>>>unbeatable in filling?  (Serious request for opinion, not yet another language
>>>flame war ignition.)
>>
>>Mathematical calculations.  The science, engineering, business, and
>>other groups requiring large amounts of efficient math processing have
>>overwhelmingly adopted Fortran for decades.
>
>
>Gee, thanks.  I didn't know that.
>
>Sigh.  I suppose I didn't ask it well -- I meant " what is it about Fortran that
>makes it unbeatable as a language for the niche *Juan Carlos* considers it to
>fill?"

Do you think he was talking about any niche other than mathematical
calculations, if you knew that was the thing Fortran was great at?
Please don't give me an ignorant attitude for the obvious, if you have
some other dumb motivation for being a pain.

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

Re: Why C++ is successful

[Jeffrey C. Dege]

On Wed, 29 Jul 1998 23:24:18 -0600, Larry Elmore <ljelmore@montana.campus.mci.net> wrote:
>Ell wrote in message <35c0edf6.9796817@news.erols.com>...
>>
>>Mathematical calculations.  The science, engineering, business, and
>>other groups requiring large amounts of efficient math processing have
>>overwhelmingly adopted Fortran for decades.
>
>But isn't this largely due to a combination of inertia, legacy code,
>existing libraries plus compilers that are very, very good at optimizing
>that kind of code (they've certainly had enough time to get them working
>right!), rather than anything to do with the language itself?

Partly, but Fortran also has the advantage of lacking pointers.  The fact
that C/C++ allow you to modify a variable through pointers in non-obvious
ways put real limits on what sort of optimizations the compiler can safely
make.  Fortran back when I used it was also strictly a static language
i.e., all local variables were, in C terms, statically allocated, out
of BSS, not allocated off the stack on function entry, and all arguments
were pass-by-reference.  This made function entry and exit much faster.
(no stack frames to release, no copying of pass-by-value arguments, etc.)
Of course, this also meant no recursive function calls.

Again, this lead to simplified variable access patterns, as compared to
C/C++, which meant more aggressive optimization was possible without
the risk of breaking legal code.  
-- 
First twenty-one new features that somehow we must add in.
    Then thirty-seven changes show up much to our chagrin.
And this thing's just inadequate, and that one's just plain wrong.
    And by the way your schedule is about three months too long.

Re: Why C++ is successful

[dennison]

In article <35C00670.56E78687@earthlink.net>,
  Jay Martin <jaymmartin@earthlink.net> wrote:
> Pat Rogers wrote:
> > Since you mention it, what would you say is Fortran's niche that the
language is
> > unbeatable in filling?  (Serious request for opinion, not yet another
language
> > flame war ignition.)
>
> I believe Fortran (i.e. High Performance Fortran) is king for
> scientific array calculations on massively parallel
> machines.  These compilers will take a program
> that does calculations on arrays and generate code
> that distributes the arrays across all the processors
> and efficiently schedules data communication between
> the processors.  I don't know if there is a
> viable "High Performance C/C++" in the market yet.

I just finished a graduate-level course in compiler optimizations on
concurrent architectures. There is a large amount of research being poured
into getting Fortran compilers to optimize code on vector and multiprocessor
machines. This has little to do with the suitability of Fortran, but is
mostly due to the fact that the purchasers of these machines have lots of
Fortran code they want to run.

HPF has special loop constructs that map directly to "do this instruction on
every processor in parallel" and "do this instruction across the whole array
at once as a vector". These allows the s/w developer to explicitly code
parallelsim that he knows his hardware supports. Of course the coder has to
be able to think in these terms, which takes some getting used to.

That being said, I noticed two things wrt supporting other languages on these
platforms. First, because of C's universal reliance on pointers, just about
every loop optimization that we studied would have to be disabled in a C
compiler. Safely doing most optimizations would entail very complicated alias
analisis, usually going across compilation units.

Secondly, because of Ada's parameter passing rules and static type checking,
an Ada compiler would actually have to do LESS work than the HPF compiler to
optimize the same algorithm. The entire semester I found myself asking the
instructor, "Gee, you wouldn't have to do any of this work you just spent
half the class going over if the language was defined to (insert Ada language
rule here), would you?" Of course Ada does support pointers, but dosen't have
C's aliasing problem since aliased variables are much rarer, and have to be
clearly marked as such in the source code.

Of course language suitability is only part of the picture. If all the
purchasers of these machines have Fortran code they want to run on them, a
really great Ada or C compiler won't do them much good.

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Why C++ is successful

[Robert I. Eachus]

In article <35BF49E8.136D75C2@earthling.net> Charles Hixson <charleshixson@earthling.net> writes:

 > But what Ada REALLY needs is a good garbage collection mechanism.  And
 > saying "Do it by hand" doesn't qualify as good!

   The Ada philosophy is to give the programmer the tools he needs and
to allow him the freedom to create types (classes) that do what is
required for that type.  Of course there are also predefined types and
where appropriate there are directions given to the compiler writers
about those types:

   A.4.4(106): 

                     Implementation Advice

   Bounded string objects should not be implemented by implicit
pointers and dynamic allocation.


   A.4.5(88):

                     Implementation Requirements

  No storage associated with an Unbounded_String object shall be lost
upon assignment or scope exit.

    Now if you are creating a type that needs special storage
management, my experience is that it requires about six lines.  If you
are creating something more ordinary, just use components of
predefined types like Unbounded_String, and don't worry about garbage
collection.

     Yes, it is possible to write code in Ada that leaks
memory absent garbage collection, but is well behaved if garbage
collection is provided, as it is by some implementations.  But such
programs are rare.  For the large majority of Ada programs, memory
management is not an issue.  (Or at least, it isn't an issue if there
ISN'T a garbage collector.)   For a much smaller set, but probably much
larger than the set where general garbage collection is helpful, you
do need to put in some storage management code.  But with Ada 95, the
most I have ever had to do was about one page of code.  (Create a type
descended from Controlled that cleans itself up when no longer visible
by calling Unchecked_Deallocation.  These objects are often used for
communication between tasks where a simple protected type won't
do. However, I'd say that 90% of such cases all you have to do is use
Unbounded_Strings.)

    I'll post a very useful example to comp.lang.ada soon.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Why C++ is successful

[Ell]

In comp.object Larry Elmore <ljelmore@montana.campus.mci.net> wrote:
: Ell wrote in message <35c0edf6.9796817@news.erols.com>...
:>"Pat Rogers" <progers@acm.org> wrote:
:>
:>>Juan Carlos Gil Montoro wrote in message <35BF51A2.B199FDFA@gmv.es>...
:>>>Pat Rogers wrote:

:>>>> That's why I'm learning Java now, and Eiffel and C++ in the past.  They
: all
:>>>> contribute something to make one a better developer.  I need to take
: another
:>>>> look at Fortran, because it sure isn't the Fortran IV I used in the old
:>>>> days!

:>>>  You'll be happy you did.
:>>>  Fortran 90 and Fortran 95 are modern languages unbeatable (IMHO) in
:>>>their niche.

:>>Since you mention it, what would you say is Fortran's niche that the
: language is
:>>unbeatable in filling?

:>Mathematical calculations.  The science, engineering, business, and
:>other groups requiring large amounts of efficient math processing have
:>overwhelmingly adopted Fortran for decades.

: But isn't this largely due to a combination of inertia, legacy code,
: existing libraries plus compilers that are very, very good at optimizing
: that kind of code (they've certainly had enough time to get them working
: right!), rather than anything to do with the language itself?

Fortran has been one of, if the best overall best language for math
calculation since it appeared in the '50's.  It was the 1st high level
language suitable for complex math.  It's 3 or 4 the revision allowed
asssembler to be easily mixed into its source, and it had nicely optimized
compiler's which produced efficient code.  For fast, complex math I still
think it outshines the other--especially amongst most widely used, well
known languages.

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

Re: Why C++ is successful

[Charles Hixson]

Yes, I know what the current Ada spec is on this.  I was also informed
(forget which book) that routines in library units are not guaranteed to
ever clean themselves up (during the life of the program).  Annoying. 
And, yes, I know that those compilers that host themselves on JVM's make
use of the embedded garbage collector, but there doesn't seem to be any
syntax, and certainly no standard syntax, to control it.  At least Java
lets you ASK the gc to start.  It doesn't have to do it, but you can
ask.
Basically, I'm very attracted to Ada95.  But there are these few little
problems:  no standard screen controls (need to use some other standard
language for that, I guess).  No standard gc (yes, I do need to look
into descendants of controlled, but the examples that I've seen so far
haven't left me feeling optomistic -- basically, if I have a structure
with multiple pointers, say a balanced tree with some cursors, there
doesn't seem to be any safe way to determine when I can free the node,
without a WHOLE LOT of hand waving (sentinals, freeable storage lists,
synchronization flags, etc.), so how do I balance the tree?  I know in
Java that there's a huge amount of *stuff* going on in the background,
and it would be v. nice to eliminate this on structures that don't need
it.  Especially on arrays, etc., of "homogenous type".  But I wonder if
the gain of eliminating the overhead (and for getting those VERY USEFUL
type checks and range types) pays for the cost of user maintained
dynamic types.  This is the second time I have devoted a month or two to
Ada95, because it seems to be SO desireable.  Then I hit one of these
bottlenecks, estimate the amount of time it will take to implement the
feature I'm looking at, and back off again.
But if a standard approach were defined, then even if the particular
compiler that I was using didn't implement it (i.e., optional annex), at
least I would know what syntax my solution should use, so as to be
maximally portable.

I don't want to build in storage leaks, assuming a garbage collector,
when most implementations don't have one.

Robert I. Eachus wrote:
> 
> In article <35BF49E8.136D75C2@earthling.net> Charles Hixson <charleshixson@earthling.net> writes:
> 
>  > But what Ada REALLY needs is a good garbage collection mechanism.  And
>  > saying "Do it by hand" doesn't qualify as good!
> 
>    The Ada philosophy is to give the programmer the tools he needs and
> to allow him the freedom to create types (classes) that do what is
> required for that type.  Of course there are also predefined types and
> where appropriate there are directions given to the compiler writers
> about those types:
	/* snip */ 
> do need to put in some storage management code.  But with Ada 95, the
> most I have ever had to do was about one page of code.  (Create a type
> descended from Controlled that cleans itself up when no longer visible
> by calling Unchecked_Deallocation.  These objects are often used for
> communication between tasks where a simple protected type won't
> do. However, I'd say that 90% of such cases all you have to do is use
> Unbounded_Strings.)
> 
>     I'll post a very useful example to comp.lang.ada soon.
> --
> 
>                                         Robert I. Eachus
> 
> with Standard_Disclaimer;
> use  Standard_Disclaimer;
> function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Why C++ is successful

[Robert Dewar]

Jeffrey said

<<Partly, but Fortran also has the advantage of lacking pointers.  The fact
that C/C++ allow you to modify a variable through pointers in non-obvious
ways put real limits on what sort of optimizations the compiler can safely
make.  Fortran back when I used it was also strictly a static language
i.e., all local variables were, in C terms, statically allocated, out
of BSS, not allocated off the stack on function entry, and all arguments
were pass-by-reference.  This made function entry and exit much faster.
(no stack frames to release, no copying of pass-by-value arguments, etc.)
Of course, this also meant no recursive function calls.
>>

This is old fashioned thinking, on modern processors, the normal situation
is that accessing static global memory is more expensive than accessing
local stack storage. 

Note incidentally that Fortran is carefully designed to give the implementor
the choice between using static and stack storage (i.e. the characterization
of "strictly static" applies to the *implementation* not the *language*)

It is also not at all the case that passing by reference is necessarily
faster than passing by copy, and many Fortran compilers use pass by 
copy for simple variables.

Re: Why C++ is successful

[Jay Martin]

Charles Hixson wrote:
> 
> But what Ada REALLY needs is a good garbage collection mechanism.  And
> saying "Do it by hand" doesn't qualify as good!

Actually, I am pretty sure Ada83 that was supposed to have garbage collection
in non-embedded environments as there were official features to turn "automatic
storage reclaimation" off.  Unfortunately, it wasn't a hard implementation
requirement and in the DOD world of $5000 toilet seats....   This is another
example of DOD mismanagement of Ada and its sad to admit in retrospect
that the Ada scoffers were right (DOD and competent language management
do not mix).  Russia leaving the cold war business didn't help Ada either.
Oh well, the time to get on the Ada bandwagon was 15 years ago. 

Jay

Re: Why C++ is successful

[Jay Martin]

Robert Dewar wrote:
> 
> Jay says
> 
> <<Actually, I am pretty sure Ada83 that was supposed to have garbage collection
> in non-embedded environments as there were official features to turn "automatic
> storage reclaimation" off.  Unfortunately, it wasn't a hard implementation
> requirement and in the DOD world of $5000 toilet seats....   This is another
> example of DOD mismanagement of Ada and its sad to admit in retrospect
> that the Ada scoffers were right (DOD and competent language management
> do not mix).  Russia leaving the cold war business didn't help Ada either.
> Oh well, the time to get on the Ada bandwagon was 15 years ago.
> >>
> 
> No, that is wrong, Ada83 was not "supposed" to have GC, it was supposed to
> ensure that GC was practical if it was needed. As for DoD mismanagement,
> this is a truly peculiar statement. Any Ada vendor would have been happy
> to provide GC to a customer who wanted it and was willing to pay. In fact
> my memory at ALsys was we never had EVEN ONE customer who was interested
> enough in GC to even ask about it. The same is true in our experience with
> GNAT.
> No customer has ever asked for GC, and they certainly have asked for many
> other things.

If you are doing embedded systems, then you can't use GC.  Unfortunately,
this dooms Ada to that niche.

Go to the source, what does Ichbiah say?  Hey Ichy, did you expect
(in 1983) for Ada83 systems for doing non-embedded applications, say business
apps, to have GC?  I would be amazed if he says no.  Look at the
Ada Booch components, not a single "free" in the whole library. 
Surely, he Booch was expecting GC.

> 
> You can of course use conservative GC's of various varieties with most
> Ada 83 and Ada 95 compilers. I never bumped into an Ada application that
> took advantage of this possibility.
> 
> I think that the DoD would have been way out of line dictating what particular
> implementation characteristics were needed in implementations of Ada, instead
> of leaving this up to the individual projects.

They can turn off the GC. I don't see what your problem with having a
GC requirement on a Ada83 for a business system. 

IMHO, the DOD free market Ada compiler experiment was a complete failure.  
Free markets don't work in the defense field. The should have paid a
set of Ada vendors whatever $$$ it took (maybe you) back in early 80's to
build and maintain a suite of Ada compilers and then gave them all away
for massive number of system configurations. Heh, there should have been
GCC_Ada1, GCC_Ada2 and GCC_Ada3.  Then they should have paid massive bucks
to these venders to have every system library known to man to have an Ada
version almost immediately.  How many billions would it have taken for success?

> 
> The fact that users of Ada did not ask for Jay's pet-feature-of-the-day has
> nothing to do with mismanagement, and everything to do with actual requirements.

The mismanagement is that the DOD did not push Ada beyond the immediate
requirements of defense embedded systems.  Its a chicken or the egg
situation:  You can't portably rely on GC until a good number of compilers
support it, so nobody uses it and thus there is no pressing demand for it.
This is where management needs to step in and break the cycle.

Jay

Re: Why C++ is successful

[Robert Dewar]

Jay says

<<Actually, I am pretty sure Ada83 that was supposed to have garbage collection
in non-embedded environments as there were official features to turn "automatic
storage reclaimation" off.  Unfortunately, it wasn't a hard implementation
requirement and in the DOD world of $5000 toilet seats....   This is another
example of DOD mismanagement of Ada and its sad to admit in retrospect
that the Ada scoffers were right (DOD and competent language management
do not mix).  Russia leaving the cold war business didn't help Ada either.
Oh well, the time to get on the Ada bandwagon was 15 years ago.
>>


No, that is wrong, Ada83 was not "supposed" to have GC, it was supposed to
ensure that GC was practical if it was needed. As for DoD mismanagement,
this is a truly peculiar statement. Any Ada vendor would have been happy
to provide GC to a customer who wanted it and was willing to pay. In fact
my memory at ALsys was we never had EVEN ONE customer who was interested
enough in GC to even ask about it. The same is true in our experience with
GNAT.
No customer has ever asked for GC, and they certainly have asked for many
other things.

You can of course use conservative GC's of various varieties with most
Ada 83 and Ada 95 compilers. I never bumped into an Ada application that
took advantage of this possibility.

I think that the DoD would have been way out of line dictating what particular
implementation characteristics were needed in implementations of Ada, instead
of leaving this up to the individual projects.

The fact that users of Ada did not ask for Jay's pet-feature-of-the-day has
nothing to do with mismanagement, and everything to do with actual requirements.

Please note that, as you of course know, I have always considered GC a
very important feature in high level languages. I find it disappointing
that it has been impossible to interest either Ada users or the Ada 9X
design process in GC, but that's the way it was. I had hoped to get GC as
at least a recommended part of the IS annex, but even there, I found zero
support on the relevant committee, and indeed, seeing the lack of interest
in GC among Ada users, I think the Ada 9X design had the right idea. Enable
GC at the design level, but do not attempt to impose it.

Re: Why C++ is successful

[Matthew Heaney]

Jay Martin <jaymmartin@earthlink.net> writes:

> Look at the Ada Booch components, not a single "free" in the whole
> library.  Surely, he Booch was expecting GC.

This is incorrect.

His reason for not using Free is NOT because he was "expecting GC."  He
explains in his book that he didn't use Unchecked_Deallocation because
it is non-portable.

The Booch components had a very specific taxonomy.  Only "unmanaged"
components expect a garbage collector.  The "managed" forms do their own
garbage collection (using a storage manager, another component).  

In practice, for a data structures library, a garbage collector is NOT
necessary.  Ada 95 gives you all the tools you need to implement memory
reclaimation yourself, very simply.

Re: Why C++ is successful

[Matthew Heaney]

Jay Martin <jaymmartin@earthlink.net> writes:

> The mismanagement is that the DOD did not push Ada beyond the immediate
> requirements of defense embedded systems.

This statement is a bit ironic, since you often hear the opposite
complaint: that Ada (83) went too far in trying to be an all-purpose
language, and that the DoD should have settled for a _smaller_ language,
with only the features specifically required for "defense embedded
systems."

It was during his Turing Award speech that Tony Hoare warned that "the
fate of mankind" was a stake because Ada included ... exceptions!
Imagine what he'd say about a language that mandated garbage collection.

The perception in the software community (largely due to Hoare's speech)
was that Ada was "too large and complex."  You would never have sold the
language had it thrown in a garbage collector too.

And as Robert has pointed out in this and other threads, GNAT customers
aren't much interested in GC.

Matt

P.S.  The debate about languages being "complex" vs "feature-rich" was
debated a few weeks back on comp.object.  Get thee to dejanews for the
gory details.  (Hint: Ada is a large language, but not "complex" in the
sense that is usually bandied about.)

Re: Why C++ is successful

[Jay Martin]

Matthew Heaney wrote:
> 
> Jay Martin <jaymmartin@earthlink.net> writes:
> 
> > Look at the Ada Booch components, not a single "free" in the whole
> > library.  Surely, he Booch was expecting GC.
> 
> This is incorrect.

Booch did expect GC:

"Unmanaged -> Automatic garbage collection is the responsibility
of the underlying run time system and compiler."

> His reason for not using Free is NOT because he was "expecting GC."  He
> explains in his book that he didn't use Unchecked_Deallocation because
> it is non-portable.

Which turned out to be a technical mistake, because 
I didn't remember a (non-embedded system) Ada compiler that did
not implement "Unchecked_Deallocation".   Imagine
the ridicule from C programmers: "You can call malloc
but you can't even call free!."
 
> The Booch components had a very specific taxonomy.  Only "unmanaged"
> components expect a garbage collector.  The "managed" forms do their own
> garbage collection (using a storage manager, another component).

Which excepting multi-tasking and fixed sized forms, made up for
roughly half the Booch components, over a 100
component permutation banking on GC.

Jay

Re: Why C++ is successful

[Lars Farm]

Matthew Heaney <matthew_heaney@acm.org> wrote:

> It was during his Turing Award speech that Tony Hoare warned that "the
> fate of mankind" was a stake because Ada included ... exceptions!
> Imagine what he'd say about a language that mandated garbage collection.

Are you saying tht GC would introduce a larger risk for incorrect
programs than exceptions? If so, why?


-- 
Lars Farm; lars.farm@ite.mh.se  -  Limt/Channelmatic: lars.farm@limt.se

Re: Why C++ is successful

[Matthew Heaney]

lars.farm@ite.mh.se (Lars Farm) writes:

> Matthew Heaney <matthew_heaney@acm.org> wrote:
> 
> > It was during his Turing Award speech that Tony Hoare warned that "the
> > fate of mankind" was a stake because Ada included ... exceptions!
> > Imagine what he'd say about a language that mandated garbage collection.
> 
> Are you saying tht GC would introduce a larger risk for incorrect
> programs than exceptions? If so, why?

What I was trying to say is that Hoare objected to the size of the
langauge.  Mandating garbage collection would only have made the
language larger.

I'm only guessing what Tony would think.  Maybe he'd actually like
having a garbage collector.

Re: Why C++ is successful

[Matthew Heaney]

Jay Martin <jaymmartin@earthlink.net> writes:

> Which turned out to be a technical mistake, because 
> I didn't remember a (non-embedded system) Ada compiler that did
> not implement "Unchecked_Deallocation".   Imagine
> the ridicule from C programmers: "You can call malloc
> but you can't even call free!."

It was probably too conservative, since the RM recommends that an
implementation really support UC.  And all implementations of Ada really
do support UC.

But even if he did use UC in the implementation of his unmanaged forms,
this isn't good enough, since the client would still have to explicitly
Clear the structure prior to exiting the scope of its declaration.
Otherwise a memory leak would occur.  This is what you have to do in the
managed forms too.

I've written an Ada95 data structures library very much like what Booch
provided, that does automatic garbage collection.  It wasn't that hard.

> > The Booch components had a very specific taxonomy.  Only "unmanaged"
> > components expect a garbage collector.  The "managed" forms do their own
> > garbage collection (using a storage manager, another component).
> 
> Which excepting multi-tasking and fixed sized forms, made up for
> roughly half the Booch components, over a 100
> component permutation banking on GC.

His taxonomy provides a menu from which you choose the forms that apply
to your situation.  You are not expected to use all the forms.

The functionality is the same in both the managed and unmanaged forms.
Just stick to the managed forms, and no GC is necessary.

That "roughly half" of his library "banks on GC" in a weak argument,
because you never use that half of the library.

If the fact that half the library goes unused upsets you, then just go
the the directory where you keep the components, and delete the
unmanaged forms.  After you do that, then _none_ of the library will
depend on GC.  And you'll have lots of extra disk space too!

Re: Why C++ is successful

[Lars Farm]

Matthew Heaney <matthew_heaney@acm.org> wrote:

> What I was trying to say is that Hoare objected to the size of the
> langauge.  Mandating garbage collection would only have made the
> language larger.

Wouldn't GC make the language smaller? For instance in C++ you could
remove delete and delete[] without adding any syntax at all. One might
perhaps even argue about the value of destructors other constructs if
there was mandatory GC. As far as I can see GC would simplify a
language. Definitely from the users point of view. Perhaps not as seen
by a compiler writer. OTOH the reason we have higher level languages
must be to simplify for those using the language, rather than those
implementing the compilers so I think "smaller" must be taken in the
users context.

> I'm only guessing what Tony would think.  Maybe he'd actually like
> having a garbage collector.

One data point is a text he wrote with Dahl in Dahl, Dijkstra, Hoare:
Structured Programming, 1972. They talk about OOP using Simula and argue
that GC is a requirement (p179).


-- 
Lars Farm; lars.farm@ite.mh.se  -  Limt/Channelmatic: lars.farm@limt.se

Re: Why C++ is successful

[Robert Dewar]

Jay said

<<The mismanagement is that the DOD did not push Ada beyond the immediate
requirements of defense embedded systems.  Its a chicken or the egg
situation:  You can't portably rely on GC until a good number of compilers
support it, so nobody uses it and thus there is no pressing demand for it.
This is where management needs to step in and break the cycle.
>>

There are LOTS of applications of Ada that have nothing to do
with embedded systems. It is just that none of these have needed garbage
collection. Note that your criticism would also apply to C++ (though
presumably not even Jay can manage to blame the DoD for this :-)

Sure, Jay thinks GC is an important feature, but this is by no means
a universal attitude. Algol-68 tried to move GC into the mainstream,
so did Modula-3, both failed in this goal. Java is making another
attempt, perhaps it will succeed.

The fact remains that the reason that Ada compilers do not implement
general GC (although of course they can be used with typical conservative
GC gizmos) is that users have not been interested in this feature, and
that includes users with a very wide range of applications.

P.S. if you insist on referring to Jean Ichbiah as Ichy, perhaps we should
refer to you as Mary :-). But in any case I doubt you will get a reply
from Jean, since he is no longer in the Ada world (he works on some
very nice products these days, if you have a Palm Pilot, try visiting
his web site if you don't like Graffiti :-)

In fact Jean was careful to design Ada 83 so that it was compatible with
garbage collection, and Dave Fisher most certainly *did* expect all
or most implementations to implement GC. But Jean's company, Alsys, never
implemented general GC in Ada -- why not -- simple, none of their customers
needed it or even particularly wanted it.

P.P.S. I guess Jay feels that Fortran and COBOL, both of course lacking GC,
are also suitable only for embedded defence applications???

Re: Why C++ is successful

[Robert Dewar]

Lars says

<<Are you saying tht GC would introduce a larger risk for incorrect
programs than exceptions? If so, why?
>>

Most certainly! GC introduces a huge risk for incorrect programs. Garbage
collectors assume that the pointer structure of a program is correct. If
it is corruptede, garbage collectors can cause horrible havoc. Indeed this
havoc often only shows up after several mark-and-sweep type cycles of the
GC, and it can be almost impossible to track them down

(said from horrible experiences in implementing general GC!)

Re: Why C++ is successful

[William Clodius]

Robert Dewar wrote:
> <snip>
> P.P.S. I guess Jay feels that Fortran and COBOL, both of course lacking GC,
> are also suitable only for embedded defence applications???

Minor point. Some of the UK vendors of Fortran 90/95 compilers, perhaps
because of their experience with Algol 68, have garbage collection as an
option. This is certainly true of NAG's compiler, and I think I have
read of similar capabilities for Salford (based on NAG's compiler), and
NASoftware (developed by the developers of perhaps the sole remaining
commercial implementation of Algol 68).

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: Why C++ is successful

[Martin Dowie]

In article <dewar.902414782@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
writes
>
>Jay said
>
><<The mismanagement is that the DOD did not push Ada beyond the immediate
>requirements of defense embedded systems.  Its a chicken or the egg
>situation:  You can't portably rely on GC until a good number of compilers
>support it, so nobody uses it and thus there is no pressing demand for it.
>This is where management needs to step in and break the cycle.
>>>
another reason GC is not used/wanted is that in many embedded systems
the last thing you want is some autonomous GC being scheduled just when
you're in the tight-for-time bit of the code...

-- 
Martin Dowie

Re: Why C++ is successful

[harald.mueller]

In article <dewar.902415458@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>
> Lars says
>
> <<Are you saying tht GC would introduce a larger risk for incorrect
> programs than exceptions? If so, why?
> >>
>
> Most certainly! GC introduces a huge risk for incorrect programs. Garbage
> collectors assume that the pointer structure of a program is correct. If
> it is corruptede, garbage collectors can cause horrible havoc. Indeed this
> havoc often only shows up after several mark-and-sweep type cycles of the
> GC, and it can be almost impossible to track them down
>
> (said from horrible experiences in implementing general GC!)
>

Now that's interesting. I did never write a GC, but I wrote a heap management
system, which had bugs in it for the first few weeks, and you wouldn't
believe it: A correct GC would have been MUCH BETTER than my wrong heap
management. So?

Actually, the problem with new/delete schemes is that the *user*(!!) can
corrupt the heap, e.g. by deleting stack variables:

f(C* p) {
   C defaultC;
   C* c;
   if (p == null) c = &defaultC;
   else c = p;
   ...
   ...
   ...
   delete c;
}

Similar with static class variables etc. You wouldn't believe how many heaps
silently and very late crash after such errors (which are mostly introduced
innocently during maintenance - "we dont have to create a new C all the time -
just let's have a single static one").

HMMueller

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Why C++ is successful

[Brian Rogoff]

On Fri, 7 Aug 1998 harald.mueller@siemenscom.com wrote:
>   dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> > Most certainly! GC introduces a huge risk for incorrect programs. Garbage
> > collectors assume that the pointer structure of a program is correct. If
> > it is corruptede, garbage collectors can cause horrible havoc. Indeed this
> > havoc often only shows up after several mark-and-sweep type cycles of the
> > GC, and it can be almost impossible to track them down
> >
> > (said from horrible experiences in implementing general GC!)
> 
> Now that's interesting. I did never write a GC, but I wrote a heap management
> system, which had bugs in it for the first few weeks, and you wouldn't
> believe it: A correct GC would have been MUCH BETTER than my wrong heap
> management. So?

I have nothing against GC, in fact I like it in general and wish its use
was more widespread, but a very large part of your problem is that the
language you are working in 

(1) Doesn't distinguish between pointers to local variables and pointers 
    to heap allocated memory.

(2) Allows you to get a pointer to any local variable, rather than forcing 
    you to be explicit about which local variables can be pointed to, or 
    "aliased". 

(3) Makes it easy to do all kinds of other arbitrary weird things with
    pointers. 

In an otherwise very similar language, Ada, none of these are a problem. 
Sure, the user could always declare every local variable as aliased, and 
make every pointer "access all" to point to heap and local variables, and 
insist on using Unchecked_Access ("&" in C/C++) and Unchecked_Conversion 
(casting) to turn off all the checks, but the presence of "Unchecked_" 
anything tells you where the problem might be. Modula-3 has the
requirement that any module which uses unsafe features of the language 
be labelled as UNSAFE, which is an idea I like too, though it also has 
GC so you proabbly wouldn't write allocators in M3. 

I tend to think of Ada as being semantically similar to C++ (especially
wrt to the fact that Ada allows low level programming), except that 
while C++ allows you to be safe, the defaults are unsafe, and while 
Ada allows you to be unsafe, the defaults are safe. Since I'm sort of a 
slapdash programmer, I prefer help from the compiler to avoid the sort of 
mishaps Harald describes. Doubtless the C++ experts out there who are
writing reliable code are a lot smarter than me and don't need this kind
of help, or they get it by using tools like Lint and Purify; probably
both. I don't have the same problems in Ada that I do in C or C++, even 
though I'm *far* more familiar with C than Ada (I use C every day).

-- Brian

Re: Why C++ is successful

[Timothy Welch]

On Fri, 7 Aug 1998 13:21:17 -0700, Brian Rogoff
<bpr@shell5.ba.best.com> wrote:

>I have nothing against GC, in fact I like it in general and wish its use
>was more widespread, but a very large part of your problem is that the
>language you are working in 
>
>(1) Doesn't distinguish between pointers to local variables and pointers 
>    to heap allocated memory.
>
>(2) Allows you to get a pointer to any local variable, rather than forcing 
>    you to be explicit about which local variables can be pointed to, or 
>    "aliased". 
>
>(3) Makes it easy to do all kinds of other arbitrary weird things with
>    pointers. 
>

Out of curiousity why are (1) and (2) problems? Can't the GC just
check to see if the pointer is pointing to memory on the stack?


Tim

Re: Why C++ is successful

[Jason Stokes]

-----BEGIN PGP SIGNED MESSAGE-----

In article <dewar.902415458@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
wrote:

>Most certainly! GC introduces a huge risk for incorrect programs. Garbage
>collectors assume that the pointer structure of a program is correct. If
>it is corruptede, garbage collectors can cause horrible havoc. 

Question: how does the pointer structure of a program get corrupted? 
Not by being "incorrect", since a language that implements garbage
collection (properly) doesn't give programs control over the pointer
structure of objects in memory.  That's a compiler managed detail.  So,
all you are saying is that programs can't be guaranteed to fufil their
specification if they are compiled with a buggy compiler or if they run
on memory hardware that's prone to errors.  That isn't a garbage
collection problem, it's a general problem of implementation.

Perhaps you are thinking of languages like C++ that have pointers and
manual memory management and hence offer eminent chances for incorrect
programs to corrupt their pointer structure with dangling references
and memory leaks.  If so, you are right; 100% safe garbage collection
for C++ is indeed impossible.  Not so for other languages.

- -- 
Jason Stokes: jstok@valis.apana.org.au
 See my homepage: http://bluedog.apana.org.au/~jstok/index.html
  for my PGP key.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQCVAwUBNcuTPDXsitsNFJm1AQG6yAP/Z7Pv4yIYJB55igj6bWAQ0KlY0cwpz384
OAMoiIy8N1iqY6vHQfFdHfRJcH28wLEYIBlmAFtns1Smw6XiF0hfXt9jVUqDG2Ve
nv/MojblTEtAMGuvca7BafwreOYVUJM5nbfX4nW3ADi/BXX7TL4IgFBCBIiCkEEm
dOhgsCmNHbI=
=2Qe7
-----END PGP SIGNATURE-----

Re: Why C++ is successful

[Robert Dewar]

HMMueller says

<<Actually, the problem with new/delete schemes is that the *user*(!!) can
corrupt the heap, e.g. by deleting stack variables:
>>

Sure, that is *precisely* the problem, in a totally protected high level
language (LISP, SNOBOL4, Pure Java etc), you can ensure that the heap
maintains its integrity. The only worry is the correctness of the heap
implementation itself, and this is a problem that can be solved.

But if you allow low level stuff, which is typically a requirement in
embedded applications, then that low level stuff can corrupt pointers.
WIth corrupted pointers around, a perfectly correct garbage collector
can cause unimaginable chaos. 

One time working on the 1108 SPITBOL, we had a case of major heap
corruption, that finally (after looking through several linear feet
of dumps) we realized reflected an error in an imported assembly
language routine, that did not bring things to a grinding halt
till 26 garbage collections later. The small error sort of spread
like a cancer, getting worse on each GC, until it finally crashed.

Now to be fair, this was a mark/sweek/compact collector, and such
collectors are far less robust with respect to this kind of sabotage
than non-compacting collectors.

Re: Why C++ is successful

[Michael Young]

That's a particularly unfortunate citation. The author, Ian Joyner,
demonstrates small understanding of OOP and C++. We can discuss each of
his points one by one, if you like, but I believe you'll agree after a
cursory reading.

Michael.

nabbasi@earthlink.net wrote:
> 
> In article <6pmmd7$5t7@gcsin3.geccs.gecm.com>, John says...
> 
> > My view now is that I would still like to learn C++, but only
> >really for interest, from what I know of Ada 95 and C++, Ada 95 certainly
> >seems to be the more understandable language and, with the increasing
> >size and complexity of software systems which require maintenance, I know
> >what I d rather maintain.
> >
> 
> you might be interested in this C++ critque (sp?) :
> 
> http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html
> 
> in particular this section:
> 
> http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3/sect3/
> 
> Nasser

Re: Why C++ is successful

[Robert Dewar]

Timothy Welch says

<<>(1) Doesn't distinguish between pointers to local variables and pointers
>    to heap allocated memory.
>
>(2) Allows you to get a pointer to any local variable, rather than forcing
>    you to be explicit about which local variables can be pointed to, or
>    "aliased".
>
>(3) Makes it easy to do all kinds of other arbitrary weird things with
>    pointers.
>

Out of curiousity why are (1) and (2) problems? Can't the GC just
check to see if the pointer is pointing to memory on the stack?
>>


Undoubtedly at least *part* of the problem in using C is that people are not
sufficiently aware of what can go wrong. Microsoft has a rather amazing
book that pretends to be a book about software techniques, but in fact is
little more than a set of perfectly standard coding procedures to avoid
pitfalls in C. When I read it, I was surprised that professional C 
programmers would find such a book useful, but the questions above are
a reminder that you often people are not aware of the dangers. I must
say I worry about CS curriculums in which people are only getting exposed
to C and C++ and hence simply don't register important language design
principles (after all the idea that it is obviously a bad idea to allow
pointers to local variables is a very old one, dating back at least to
Pascal, which means coming up to 30 years.

Timothy, to answer your questions.

(1) is a serious problem, since it can allow dangling pointers. That is,
when you leave a scope with such a pointer, then you have a pointer to
inactive stack. Using this pointer later on can cause serious damage, e.g.
clobbering a return point stored on the stack. These dangling pointers are
created even though you never use free. There is no practical implementation
mechanism for efficiently detecting such a dangling pointer.

(2) is of course related, but is at a more conceptual level. Aliasing is
always dangerous because it can cause code to be very difficult to read,
understand, and maintain (as well as leading to accidental bugs in the
first place). Consider in C:

	(everything is an int or a *int)

	a = b;
        c = 3 + q;
        *d = 4;
 
That assignment to *d *may* modify the values of a and c. This means you
cannot just read ahead in the code at this stage, you have to ensure that
it is not possible for d to be pointing to a or c, or worse discover that
it is possible, and that one of the first two assignments is dead.

A (good) compiler will make an attempt to determine the answer (it is not
always possible to do this reliably). A compiler that does not make this
effort risks generating horrible code for the above, since it has to forget
the values of a and c in registers. A compiler that tries hard still often
finds that it has to be conservative and assume the worst.

A (good) programmer will make an attempt to determine the answer (it is not
always possible to do this reliably). A programmer that does not make this
effort risks seriously misunderstanding the above, since they will have to
forget the assigned values of a and c. A programmer that tries hard still
often finds that they have to be conservative and assume the worst.

Note the parallel language here is quite deliberate. Whey you set obstacles
for a compiler, you set them for a programmer as well. A clever compiler
can compensate, and that's OK, since machine time is cheap, so what if the
compilation takes longer (but as noted, even a clever compiler can be fooled).
A clever programmer can compensate, and that is NOT OK, since programmer
time is not cheap, and maintenance mistakes are very costly.

In Pascal and Ada 83, a decision was made to completely disallow pointers
to local variables, and this is undoubtedly the best decision from a language
point of view.

However, especially when interfacing to other languages, this proves an
annoying restriction. For example, if you are interfacing to a language
like C that typically requires pointers to parameters to be passed, then
it is annoying not to be able to pass pointers to local variables. Ada 83
programmers would often resort to nasty low level junk (i.e. use of the
'Address attribute) for this purpose, leading to code that has all the
disadvantages discussed above, and more. Why more? Becuase (a) address gives 
untyped pointers, like void*, and (b) the semantics of whether the aliasing
attempt "works" correctly is not clear from the standard.

Ada 95 compromises by allowing you to declare a variable as aliased, which
means that it is allowable to take its "address", using the strongly typed
'Access attribute.

An Ada 95 program that declared every local variable to be aliased would be
equivalent to the C semantics (it would also be a travesty!)

Generally you should alias local variables ONLY in connection with interfacing
to foreign code. Yes, as with all rules, including this one, there are 
exceptions to this rule that are legitimate, but if you find you are using
aliased extensively, something may be wrong with your approach.

Robert Dewar

P.S. with respect to the GC part of your question, sure, you can determine
that a pointer points to the stack, but the dangling pointer case can cause
unimaginable chaos in a garbage collector. Indeed the combination of garbage
collection with semantics that allow dangling pointers is a dangerous one,
dangerous enough to make a language design quite dubious from a practical
point of view.

Re: Why C++ is successful

[Robert Dewar]

Jason says

<<Question: how does the pointer structure of a program get corrupted?
Not by being "incorrect", since a language that implements garbage
collection (properly) doesn't give programs control over the pointer
structure of objects in memory.  That's a compiler managed detail.  So,
all you are saying is that programs can't be guaranteed to fufil their
specification if they are compiled with a buggy compiler or if they run
on memory hardware that's prone to errors.  That isn't a garbage
collection problem, it's a general problem of implementation.

Perhaps you are thinking of languages like C++ that have pointers and
manual memory management and hence offer eminent chances for incorrect
programs to corrupt their pointer structure with dangling references
and memory leaks.  If so, you are right; 100% safe garbage collection
for C++ is indeed impossible.  Not so for other languages.
>>


I am thinking of languages which provide at least escape hatches for low
level mucking. Note that even languages that you think of as being very
safe often contain such escape hatches:

1. Java allows interface to C
2. SNOBOL-4 allows dynamic loading of asm functions
3. Ada allows low level mucking using chapter 13 features
4. Even SPARK has an escape catch for arbitrary low level code

Obviously not all code requires such mucking, but in the real world, nearly
every large application has some such low level mucking somewhere.

THe combination of GC with this kind of low level mucking is what is
dangerous. Of course if the LLM is carefully controlled, and isolated,
and well tested etc. then things can be controlled, but once you have
these features, it is all too common for them to be overused, and to 
be inadequately controlled.

An amazing number of programmers these days work by writing approximate junk
code, and then spend amazing amounts of time trying to bash the code into
shape using a debugger. I fear that this approach, always worrisome, becomes
positively frightening in a GC+LLM environment :-)

Re: Why C++ is successful

[Larry Elmore]

Robert Dewar wrote in message ...
>
>Undoubtedly at least *part* of the problem in using C is that people are
not
>sufficiently aware of what can go wrong. Microsoft has a rather amazing
>book that pretends to be a book about software techniques, but in fact is
>little more than a set of perfectly standard coding procedures to avoid
>pitfalls in C.

Would this be _Code Complete_, or perhaps _Writing Solid Code_?

Larry

Re: Why C++ is successful

[Jeffrey C. Dege]

On 8 Aug 1998 08:27:02 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>Undoubtedly at least *part* of the problem in using C is that people are not
>sufficiently aware of what can go wrong. Microsoft has a rather amazing
>book that pretends to be a book about software techniques, but in fact is
>little more than a set of perfectly standard coding procedures to avoid
>pitfalls in C. When I read it, I was surprised that professional C 
>programmers would find such a book useful, but the questions above are
>a reminder that you often people are not aware of the dangers. 

If you're talking about Steve McGuire's books, (Code Complete, Writing
Solid Code), I'm a professional C programmer, and I didn't find anything
in them that I hadn't been aware of for many years.

>I must
>say I worry about CS curriculums in which people are only getting exposed
>to C and C++ and hence simply don't register important language design
>principles (after all the idea that it is obviously a bad idea to allow
>pointers to local variables is a very old one, dating back at least to
>Pascal, which means coming up to 30 years.

I have to agree with the above.  A CS curriculumn should have some breadth
to it.  Exposure to a variety of languages is a part of this, as is
instruction in the theory underlying compilers.

-- 
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" ("I found it!") but rather "hmm....that's
funny..."  --   Isaac Asimov

Re: Why C++ is successful

[Phlip]

>...Microsoft has a rather amazing
>book that pretends to be a book about software techniques, but in fact
is
>little more than a set of perfectly standard coding procedures to avoid
>pitfalls in C...

Yeah - especially things like "Don't write very long functions."

What a pity that MS does not change to Eiffel immediately, where the
language spontaneously prevents this bad practice!

  --  Phlip
======= http://users.deltanet.com/~tegan/home.html =======

Re: Why C++ is successful

[Patrick Logan]

In comp.object Jeffrey C. Dege <jdege@jdege.visi.com> wrote:

: A CS curriculumn should have some breadth to it.  Exposure to a
: variety of languages is a part of this, as is instruction in the
: theory underlying compilers.

I agree. And would go further that it should not simply include an
exposure to a variety of languages, but it should include an
understanding of the underlying principles and theory of the
languages. E.g. an understanding of denotational semantics.

And the theory underlying compilers should be augmented with the
experience of implementing a series of interpreters for some language
with progressively more features, as well as an implementation of at
least a simple compiler for one version of that language.

-- 
Patrick Logan    (H) mailto:plogan@teleport.com 
                 (W) mailto:patrickl@gemstone.com 
                 http://www.gemstone.com

Re: Why C++ is successful

[Patrick Logan]

In comp.object Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

: One time working on the 1108 SPITBOL, we had a case of major heap
: corruption, that finally (after looking through several linear feet
: of dumps) we realized reflected an error in an imported assembly
: language routine, that did not bring things to a grinding halt
: till 26 garbage collections later. The small error sort of spread
: like a cancer, getting worse on each GC, until it finally crashed.

: Now to be fair, this was a mark/sweek/compact collector, and such
: collectors are far less robust with respect to this kind of sabotage
: than non-compacting collectors.

But it is not the intent of a GC to protect the application from these
kinds of problems. Mark/sweep is a good choice for some situations. It
cannot be criticized for not protecting against something outside its
scope.

-- 
Patrick Logan    (H) mailto:plogan@teleport.com 
                 (W) mailto:patrickl@gemstone.com 
                 http://www.gemstone.com

Re: Why C++ is successful

[Dale Stanbrough]

Timothy Welch  wrote:

" Out of curiousity why are (1) and (2) problems? Can't the GC just
  check to see if the pointer is pointing to memory on the stack?"

Which stack would you be referring to? A stack in one of the many dynamically
allocated tasks that you have allocated? What about a threaded environment?
Do you expect that GC for C or C++ environments will think about 
the Posix Threads environments?

Dale

Re: Why C++ is successful

[Robert I. Eachus]

In article <1dd4w22.16p27c7en0bswN@dialup119-1-10.swipnet.se> lars.farm@ite.mh.se (Lars Farm) writes:

 > Are you saying tht GC would introduce a larger risk for incorrect
 > programs than exceptions? If so, why?

   When I write software in Ada that requires storage management, part
of the testing is that 1) all storage that is allocated is later
freed, and 2) it is possible to characterize a limit on maximum memory
usage in terms of user understandable parameters.

   The amount of effort to do this is relatively trivial, or has been
every time I have had to consider the issue.  Occaisonally I have
found "errors" in the form of unrecoverd memory, and that always
resulted from an obscure bug such as simultaneous updates where one
process violated locking conventions.  (In Ada 83, in Ada 95 protected
objects seem to have eliminated that type of bug...)

   If garbage collection was implemented, checking heap usage before
and after the program was run would be useless.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Why C++ is successful

[Laurent GUERBY]

jdege@jdege.visi.com (Jeffrey C. Dege) writes:

> On 8 Aug 1998 08:27:02 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> >
> >Undoubtedly at least *part* of the problem in using C is that people are not
> >sufficiently aware of what can go wrong. Microsoft has a rather amazing
> >book that pretends to be a book about software techniques, but in fact is
> >little more than a set of perfectly standard coding procedures to avoid
> >pitfalls in C. When I read it, I was surprised that professional C 
> >programmers would find such a book useful, but the questions above are
> >a reminder that you often people are not aware of the dangers. 
> 
> If you're talking about Steve McGuire's books, (Code Complete, Writing
> Solid Code), I'm a professional C programmer, and I didn't find anything
> in them that I hadn't been aware of for many years.
> [...]

   "Code Complete" author is Steve McConnell, not Steve McGuire.  I
think Robert talks about the latter.

   The former, "Code Complete", is a very nice book IMHO, and amongst
the languages covered there is Ada (together with C/C++/Pascal/VB).
It makes a nice advocacy package for strongly typed language BTW (you
can shoot yourself into the foot easily with language X whereas you
get an error message with language Y ;-).

   A little quote for c.l.a. readers, from the "goto" pro and cons
section (reminds me of some threads ;-):

"Finally, the goto was incorporated into the Ada language, the most
carefully engineered programming language in history. Ada was
developped long after the arguments on both sides of the goto debate
had been fully developped, and after considering all sides of the
issue, Ada engineers decided to include the goto"

-- 
Laurent Guerby <guerby@bnp-eng.remcomp.com>, Team Ada, Linux/GNU addict
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Why C++ is successful

[Darren New]

> Perhaps you are thinking of languages like C++ that have pointers and
> manual memory management and hence offer eminent chances for incorrect
> programs to corrupt their pointer structure with dangling references
> and memory leaks.  If so, you are right; 100% safe garbage collection
> for C++ is indeed impossible.  Not so for other languages.

Firstly, this has pretty much drifted off the Ada/Eiffel/Object
newsgroups. Please fix followups, which I'd do if I read any of those
groups.

Secondly, it's possible to write C++ code that can be GCed reliably. All
it requires is that the compiler not use machine addresses as the only
information in a pointer. 

int a[12];
int * b;
b = &a[5];
b += 10; // This is invalid

Here, b would be represented as the tuple <a, 12, 5, stack> (with 12 and
5 scaled appropriately for the size of integers, perhaps). If I
remember, the language standard says that the fourth line there is
illegal, as it points b more than one past the end of the array. The GC
could easily collect such pointers, but the efficiency of the
manipulations would be low enough to be painful.

When I used Pascal, there was an option you could turn on that would
catch
new(p);
q = p;
dispose(p);
q^ = 7;
new(p);
q^ = 5;

even if the second allocation landed in the same place as the first
allocation in memory. Each memory block had a counter and a pointer. The
counter said how many "new" calls had happened before this block was
allocated, and the pointer pointed to the next allocated block. Each
pointer had a counter as well. Each pointer reference could check that
the counters matched, and that the block pointed to by the pointer was
in the linked list of allocated blocks. *Lots* of overhead, but it was
helpful for the students who were using it. (And of course you could
turn it all off.)

The point being that if you break out of the mindset that C++ is
high-level assembler, all kinds of things are "possible" if inefficient.
The fact that most C++ programmers would shun such overhead merely goes
to show that either (a) machine time isn't as cheap as people think in
applications where C++ is used, or (b) C++ programmers are less worried
about correctness than efficiency. I'll let you choose which.

-- 
Darren New / Senior Software Architect / First Virtual Holdings Inc
http://www.fv.com or info@fv.com -=|=- PGP Key: ftp://ftp.fv.com/pub/fv
Fingerprint: 61 7D AF 9E 00 CC C2 ED / D8 4C D7 AA E4 C2 A0 73

Re: Why C++ is successful

[Robert I. Eachus]

In article <dewar.902579285@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 > The combination of GC with this kind of low level mucking is what is
 > dangerous. Of course if the LLM is carefully controlled, and isolated,
 > and well tested etc. then things can be controlled, but once you have
 > these features, it is all too common for them to be overused, and to 
 > be inadequately controlled.

   Or worse, in a mixed langauge environment, and all large projects
(probably even all small projects nowadays) are mixed language
projects, low level mucking which is "perfectly safe" in one language
is dangerous when the object being mucked with came from another
language.  You can even run into such problems when no mucking is
involved, but there is "automatic" conversion between types, usually
string types.

 > An amazing number of programmers these days work by writing approximate junk
 > code, and then spend amazing amounts of time trying to bash the code into
 > shape using a debugger. I fear that this approach, always worrisome, becomes
 > positively frightening in a GC+LLM environment :-)

   Let us all pray--there is too much of this code floating around.
Where I usually run into it is in dealing with computer security.
Seems like every week there is an exploitable security hole in some
major application to be dealt with.






--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Why C++ is successful

[n]

In article <dewar.902579285@merv>, dewar@merv.cs.nyu.edu says...
>
 
>An amazing number of programmers these days work by writing approximate junk
>code, and then spend amazing amounts of time trying to bash the code into
>shape using a debugger.  
>

soory, but this is called meeting the big boss deadline. it is very frequent 
occurance in the modern to post-modern computing information systems age.

got'a get that code out of the door fast, else the competition will do it 
first!

\n

Re: Why C++ is successful

[stilcom]

Jeffrey C. Dege wrote:

> If you're talking about Steve McGuire's books, (Code Complete, Writing
> Solid Code), I'm a professional C programmer, and I didn't find anything
> in them that I hadn't been aware of for many years.
>

The author of Code Complete is Steve McConnell.

    --- Stefan Tilkov

Re: Why C++ is successful

[Jeffrey C. Dege]

On Tue, 11 Aug 1998 12:41:14 +0200, stilcom@gmx.net <stilcom@gmx.net> wrote:
>
>Jeffrey C. Dege wrote:
>
>> If you're talking about Steve McGuire's books, (Code Complete, Writing
>> Solid Code), I'm a professional C programmer, and I didn't find anything
>> in them that I hadn't been aware of for many years.
>>
>
>The author of Code Complete is Steve McConnell.

If so, then I have the books confused, as well as the authors.

A few years back, I browsed through a copy of "Writing Solid Code", and
judged it to be a poorly organized mish-mash of supposedly "clever"
C++ tricks, many of which were worthless, and with no guidance
whatsoever as to when the ones that weren't would be appropriate.

My opinion of this book was poor enough that when I saw Steve McConnell's
book "Code Complete", I confused the author with Maguire, and gave it a
pass.

To tell the truth, I _still_ haven't read "Code Complete", but I have
read McConnell's "Rapid Development", and found it to be a very good
introduction to iterative and incremental development methodologies.

-- 
    "[I]n fact, I didn't know that cats _could_ grin."
    "They all can," said the Duchess; "and most of 'em do."
    "I don't know of any that do," Alice said very politely, feeling quite
pleased to have gotten into a conversation.
    "You don't know much," said the Duchess; "and that's a fact."

Re: Why C++ is successful

[Andrew Koenig]

In article <slrn6t2c51.c2.jdege@jdege.visi.com>,
Jeffrey C. Dege <jdege@jdege.visi.com> wrote:

> A few years back, I browsed through a copy of "Writing Solid Code", and
> judged it to be a poorly organized mish-mash of supposedly "clever"
> C++ tricks, many of which were worthless, and with no guidance
> whatsoever as to when the ones that weren't would be appropriate.

Hmmm... I may be misremembering, but I recall "Writing Solid Code" as
having very little, if anything, to do with C++ programming technique.
Lots of C stuff, and I'm sure there is plenty of room for differences
of opinion as to when that stuff is useful.
-- 
				--Andrew Koenig
				  ark@research.att.com
				  http://www.research.att.com/info/ark

Re: Why C++ is successful

[Andy Ward]

>   A little quote for c.l.a. readers, from the "goto" pro and cons
>section (reminds me of some threads ;-):
>
>"Finally, the goto was incorporated into the Ada language, the most
>carefully engineered programming language in history. Ada was
>developped long after the arguments on both sides of the goto debate
>had been fully developped, and after considering all sides of the
>issue, Ada engineers decided to include the goto"
>


Ahh... but have you ever found a "good" reason for using it? I have used
goto in C and Pascal in certain rare cases, but I have always found clearer
ways to code these cases in Ada.

Re: Why C++ is successful

[Matt Kennel]

On Wed, 12 Aug 1998 16:14:24 +0100, Andy Ward <ajward@adc.metrica.co.uk> wrote:
:
:
:Ahh... but have you ever found a "good" reason for using it? I have used
:goto in C and Pascal in certain rare cases, but I have always found clearer
:ways to code these cases in Ada.

"goto" is most useful in code generated by another automatic algorithm,
where its lack can sometimes cause lots of headaches.

"goto" is significantly less useful and desirable in human-crafted programs. 

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           -
* "People who send spam to Emperor Cartagia... vanish! _They say_ that
* there's a room where he has their heads, lined up in a row on a desk...
* _They say_ that late at night, he goes there, and talks to them... _they
*- say_ he asks them, 'Now tell me again, how _do_ you make money fast?'"

Re: Why C++ is successful

[nasser]

In article <dewar.903074236@merv>, dewar@merv.cs.nyu.edu says...
 
>The two obvious uses vfor gotos in Ada are
>
>1) to get a loop "continue" mechanism
>
>2) to write finite state machines encoding the state into the PC. 

what about a common exit for a function?

as we all know (offcourse :) that a function should have one
common exit. multiple retruns from inside a function can make
the function harder to maintain.

sometime it is easier to go to a common_exit label at the bottom
of the function, where some common cleanup can be done if needed,
rather than use a nested if then else to try to carry the logic
through all the way down. 

example:

   if status /= good then
      goto common_exit;
   end if;

   status = do_soemthing;

   if status /= good then
      goto common_exit;
    end if;

    status = do_another_thing

    etc..

<<common_exit>>
    return status;  -- or log error message if status not good..etc..


without a goto, one has to do:

example:

   if status = good then
      status = do_somtehing;
      if status = good then
         status = do_another_thing
      else
         etc..  -- error
       end if;
   else
      ..  -- error
   end if;
  


Nasser

Re: Why C++ is successful

[Robert Dewar]

Someone with no particular name replied to me:

<<>An amazing number of programmers these days work by writing approximate junk
>code, and then spend amazing amounts of time trying to bash the code into
>shape using a debugger.
>

soory, but this is called meeting the big boss deadline. it is very frequent
occurance in the modern to post-modern computing information systems age.

got'a get that code out of the door fast, else the competition will do it
first!
>>



On the contrary! The approach of bashing things into shape with a debugger is
incredibly inefficient. You can only afford it if you do NOT have tight 
deadlines. If you have tight deadlines, then it becomes absolutely crucial
to avoid premature coding, and to write things right the first time, because
there is not enough time for inefficient fiddling around.

Re: Why C++ is successful

[Robert Dewar]

Andy said

<<Ahh... but have you ever found a "good" reason for using it? I have used
goto in C and Pascal in certain rare cases, but I have always found clearer
ways to code these cases in Ada.
>>

The two obvious uses vfor gotos in Ada are

1) to get a loop "continue" mechanism

2) to write finite state machines encoding the state into the PC. Yes, some
people prefer case statements for this purpose, but many people prefer the
use of labels and gotos as the most obvious translation of labeled states
with arrows between them.

In general, the use of gotos makes sense if the resulting code is clearer
and easier to maintain. THat's relatively rare, but not non-existnent, and
it is quite common to run across tortured code with multiple boolean flags
which can be easily simplified using a goto. 

For example, I find the following perfectly clear:

   <<sort>> for J in 1 .. N - 1 loop
       if D (J) > D (J + 1) then
	  Swap (D(J), D(J + 1));
          goto Sort;
       end if;

It is a little tricky to program this without the goto and not make it
less clear. Actuallky many people who try this end up with a different
algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort :-)
\x1adp

Re: Why C++ is successful

[Ell]

In comp.object Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
: Andy said

: <<Ahh... but have you ever found a "good" reason for using it? I have used
: goto in C and Pascal in certain rare cases, but I have always found clearer
: ways to code these cases in Ada.
:>>

: The two obvious uses vfor gotos in Ada are

: 1) to get a loop "continue" mechanism

: 2) to write finite state machines encoding the state into the PC. Yes, some
: people prefer case statements for this purpose, but many people prefer the
: use of labels and gotos as the most obvious translation of labeled states
: with arrows between them.
:
: In general, the use of gotos makes sense if the resulting code is clearer
: and easier to maintain. THat's relatively rare, but not non-existnent, and
: it is quite common to run across tortured code with multiple boolean flags
: which can be easily simplified using a goto. 

How about to avoid procedure call stack winding and unwinding in time
critical code?

Elliott
-- 
   :=***=:  Objective  *  Pre-code Modelling  *  Holistic  :=***=:
                 Hallmarks of the best SW Engineering
         "The domain object model is the foundation of OOD."
 Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
   Copyright 1998 Elliott. exclusive of others' writing. may be copied
     without permission only in the comp.* usenet and bitnet groups.

Re: Why C++ is successful

[Jean-Pierre Rosen]

Robert Dewar a �crit dans le message ...
>2) to write finite state machines encoding the state into the PC. Yes, some
>people prefer case statements for this purpose, but many people prefer the
>use of labels and gotos as the most obvious translation of labeled states
>with arrows between them.

I agree with this one,

>For example, I find the following perfectly clear:
>
>   <<sort>> for J in 1 .. N - 1 loop
>       if D (J) > D (J + 1) then
>   Swap (D(J), D(J + 1));
>          goto Sort;
>       end if;
>
But not on this one, since:
loop
   Inner: for J in 1 .. N - 1 loop
       if D (J) > D (J + 1) then
          Swap (D(J), D(J + 1));
          exit Inner;
       end if;
end loop;
reflects the intent better (at least to my taste).

Re: Why C++ is successful

[Patrick Doyle]

In article <dewar.903074236@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>For example, I find the following perfectly clear:
>
>   <<sort>> for J in 1 .. N - 1 loop
>       if D (J) > D (J + 1) then
>	  Swap (D(J), D(J + 1));
>          goto Sort;
>       end if;
>
>It is a little tricky to program this without the goto and not make it
>less clear. Actuallky many people who try this end up with a different
>algorithm (hint: the above sort is cubic, it is NOT a quadratic bubble sort :-)

Well, the fact that you had to add that hint suggests something about
your code's clarity...  :-)

How about this:

from
	J := 1
until
	J >= N
loop
	if D(J) > D(J+1) then
		Swap (D(J), D(J+1));
		J := 1;
	else
		J := J + 1;
	end
end

You don't need a goto just to reset J to 1.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.toronto.edu

Re: Why C++ is successful

[Robert Martin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]


Jean-Pierre Rosen wrote in message <6r1e1a$mj$1@platane.wanadoo.fr>...
>Robert Dewar a �crit dans le message ...
>>2) to write finite state machines encoding the state into the PC. Yes,
some
>>people prefer case statements for this purpose, but many people prefer the
>>use of labels and gotos as the most obvious translation of labeled states
>>with arrows between them.
>
>I agree with this one,
>
>>For example, I find the following perfectly clear:
>>
>>   <<sort>> for J in 1 .. N - 1 loop
>>       if D (J) > D (J + 1) then
>>   Swap (D(J), D(J + 1));
>>          goto Sort;
>>       end if;
>>
>But not on this one, since:
>loop
>   Inner: for J in 1 .. N - 1 loop
>       if D (J) > D (J + 1) then
>          Swap (D(J), D(J + 1));
>          exit Inner;
>       end if;
>end loop;
>reflects the intent better (at least to my taste).



When I need to write a quick sort, and don't have access to a decent sort
function, then I prefer this simple structure...

bool unsorted = true;
for (int i=0; unsorted && i<(N-1); i++)
{
  unsorted = false;
  for (int j = 0; j<(N-i-1); j++)
  {
    if (d[j] > d[j+1])
    {
      swap(d, j);
      unsorted = true;
    }
  }
}


Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: Why C++ is successful

[Stefan Tilkov]

Jeffrey C. Dege wrote:

> On Tue, 11 Aug 1998 12:41:14 +0200, stilcom@gmx.net <stilcom@gmx.net> wrote:
>
[ snip ]
> To tell the truth, I _still_ haven't read "Code Complete", but I have
> read McConnell's "Rapid Development", and found it to be a very good
> introduction to iterative and incremental development methodologies.
>

Actually, "Code Complete" is a very good book. It definitely does not
encourage
C++ tricks, but gives examples of good coding practices in several
languages
(including Pascal, C, and Fortran).

It seems to be a bit outdated, though; but I'd recommend a second
edition to a
programmer anytime.

        --- Stefan Tilkov
        --- to send email, remove 'remove-this'



>
>
>
> --
>     "[I]n fact, I didn't know that cats _could_ grin."
>     "ThX-Mozilla-Status: 0009Duchess; "and most of 'em do."
>     "I don't know of any that do," Alice said very politely, feeling quite
> pleased to have gotten into a conversation.
>     "You don't know much," said the Duchess; "and that's a fact."
>

Re: Why C++ is successful

[Robert L. Spooner]

Jerry Petrey wrote:

>  However, most managers never learn this lesson and continue
> to push developers to hurry and start coding to meet those
> milstones!
>

That reminds me of a cartoon that I saw a number of years ago in
Datamation (I think) where the supervisor was saying "You guys start
coding and I'll go upstairs and find out what they want."

Regards,
Bob
--
                               Robert L. Spooner
                         Registered Professional Engineer
                               Research Assistant
                         Intelligent Control Systems Group

            Applied Research Laboratory        Phone: (814) 863-4120
            The Pennsylvania State University  FAX:   (814) 863-7843
            P. O. Box 30
            State College, PA 16804-0030       RLS19@psu.edu

Re: Why C++ is successful

[Patrick Doyle]

In article <6r1e1a$mj$1@platane.wanadoo.fr>,
Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote:
>
>But not on this one, since:
>loop
>   Inner: for J in 1 .. N - 1 loop
>       if D (J) > D (J + 1) then
>          Swap (D(J), D(J + 1));
>          exit Inner;
>       end if;
>end loop;
>reflects the intent better (at least to my taste).

Except that, if I understand this correctly, the outer loop
never terminates!  :-)

Actually, this is not a trivial matter because the original point
was about having to add flags, and that's exactly what you'd have to
do to make this outer look exit.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.toronto.edu

Re: Why C++ is successful

[Mr Ada]

Jean-Pierre Rosen wrote:

> Robert Dewar a �crit dans le message ...
> >2) to write finite state machines encoding the state into the PC. Yes, some
> >people prefer case statements for this purpose, but many people prefer the
> >use of labels and gotos as the most obvious translation of labeled states
> >with arrows between them.
>
> I agree with this one,
>
> >For example, I find the following perfectly clear:
> >
> >   <<sort>> for J in 1 .. N - 1 loop
> >       if D (J) > D (J + 1) then
> >   Swap (D(J), D(J + 1));
> >          goto Sort;
> >       end if;
> >
> But not on this one, since:
> loop
>    Inner: for J in 1 .. N - 1 loop
>        if D (J) > D (J + 1) then
>           Swap (D(J), D(J + 1));
>           exit Inner;
>        end if;
> end loop;
> reflects the intent better (at least to my taste).

All right!  How about this

for J in 1 .. N - 1 loop

  exit when (D (J) <= D (J+1);

  Swap (D (J), D (J+1));
end loop;

Re: Why C++ is successful

[Jean-Pierre Rosen]

Patrick Doyle a �crit dans le message ...
>In article <6r1e1a$mj$1@platane.wanadoo.fr>,
>Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote:
>>
>>But not on this one, since:
>>loop
>>   Inner: for J in 1 .. N - 1 loop
>>       if D (J) > D (J + 1) then
>>          Swap (D(J), D(J + 1));
>>          exit Inner;
>>       end if;
>>end loop;
>>reflects the intent better (at least to my taste).
>
>Except that, if I understand this correctly, the outer loop
>never terminates!  :-)
As did the example...

>Actually, this is not a trivial matter because the original point
>was about having to add flags, and that's exactly what you'd have to
>do to make this outer look exit.
Certainly not. I just need to put a label Outer: on it, and a statement
"exit outer" at any place where I discover that the array is sorted.

Re: Why C++ is successful

[Robert Dewar]

JPR says

loop
   Inner: for J in 1 .. N - 1 loop
       if D (J) > D (J + 1) then
          Swap (D(J), D(J + 1));
          exit Inner;
       end if;
end loop;


reflects my intent better. Amusing -- shows how difficult it is to
get rid of the goto, be clearer, *and* be correct all at the same time if
JPR can't do it right.

First the above code is obviously syntactically incorrect, since it is
missing end loop Inner. If we put in the end at the obvious point:

   loop
      Inner: for J in 1 .. N - 1 loop
          if D (J) > D (J + 1) then
             Swap (D(J), D(J + 1));
             exit Inner;
          end if;
      end loop Inner;
   end loop;

then of course we have an infinite loop, since here is no exit from the
outer loop.

An attempt like this (by a *very* experienced programmer :-) helps prove
my point I think ...

Re: Why C++ is successful

[Robert Dewar]

Patrick said

  Well, the fact that you had to add that hint suggests something about
  your code's clarity...  :-)

  How about this:

  from
          J := 1
  until
          J >= N
  loop
          if D(J) > D(J+1) then
                  Swap (D(J), D(J+1));
                  J := 1;
          else
                  J := J + 1;
          end
  end

First the hint is simply because, although the algorithmic flow of the
original is completely clear, it is my experience that when people
contort to remove the gotos, they often end up with a non-equivalent
algorithm. That says nothing about the clarity of the original, merely
the difficulty of removing the goto.

The above code is correct, but for my taste not clearer. I don't like
having a loop which at the outside looks like a perfectly normal
J from 1 .. N - 1 loop, but is not.

Here the unusual structure of this loop is buried in an inner assignment,
rather than being evident at the top level in my presentation with a goto.
But certainly people differ in tastes and perhaps some will prefer the
above, but please prefer it because it is clearer to you, NOT, as is the
case for so many programmers, simply because the goto is eliminated.

There is nothing inherently unclear about a goto, that's the important
thing. On the contrary, the semantics of a goto, intepreted in the normal
operational manner at which most programmers interpret semantics, is 
about as simple as it could be. Yes, of course it is possible to abuse
the goto and write disgusting code, but the same can be said about
any feature in any language.

Re: Why C++ is successful

[Robert Dewar]

Patrick said

  Well, the fact that you had to add that hint suggests something about
  your code's clarity...  :-)

  How about this:

  from
          J := 1
  until
          J >= N
  loop
          if D(J) > D(J+1) then
                  Swap (D(J), D(J+1));
                  J := 1;
          else
                  J := J + 1;
          end
  end

A postscript by the way is that I am not clear as to what language is
being used for the above code, but I am assuming that, unlike the case
in many languages, the until test is simply a negative while, and not
a test at the end of the loop. A test at the end of the loop is of
course quite incorrect. Personally I don't like using until as the
negation of while, since it is so well established by custom that
until means an end of the loop test.

Re: Why C++ is successful

[Robert Dewar]

Robert Martin said

  When I need to write a quick sort, and don't have access to a
  decent sort function, then I prefer this simple structure...
  
  bool unsorted = true;
  for (int i=0; unsorted && i<(N-1); i++)
  {
    unsorted = false;
    for (int j = 0; j<(N-i-1); j++)
    {
      if (d[j] > d[j+1])
      {
        swap(d, j);
        unsorted = true;
      }
    }
  }

First of all, there is nothing "indecent" about the algorithm that I gave. It 
has the merit of being by far the shortest sorting algorithm in generated
code. Yes, it is slow (cubic) but for small numbers who cares, and byt the
way it is optimal for already sorted data (it will outperform bubble sort
or simple selection sort in such a setting, because of less control overhead).

As to the above algorithm, I actually find it far more contorted. I dislike
the use of a flag that is tested on every loop to avoid an exit, but I
perfectly well understand that some people prefer very clear preconditions
on loops and do not like exits at all. Too bad that almost no compilers are
clever enough to remove the additional overhead from this approach ....

But the important thing is that the above algorithm is not at all the same
as what I presented. I did not intend to start a thread on what is or is not
the best sorting algorithm, but rather to present an example of a simple
non-finite-state machine case where many people wlil find the goto clearer.

I trust that Robert Martin is not under the impression that the code above
is equivalent computationally (i.e. same sequence of comparisons) as what
I presented!

Re: Why C++ is successful

[Robert Dewar]

JPR says

<<Certainly not. I just need to put a label Outer: on it, and a statement
"exit outer" at any place where I discover that the array is sorted.
>>

Kindly then, please do so, we know the principles, the point is the example.
You posted a program that was syntactically incorrect, and also contained
a fundamental semantic error. It is not so easy asyou think to avoid the
flag here, please try -- don't just say you can do it without proving it!

Re: Why C++ is successful

[Robert Dewar]

Mr. Ada proposes

for J in 1 .. N - 1 loop

  exit when (D (J) <= D (J+1);

  Swap (D (J), D (J+1));
end loop;



Oh dear, this sure is simpler than what I wrote, but a very cursory
look at it indicates that it must be linear, so it is unlikely to be
able to sort anything and indeed it does not.

Perhaps that is the remarkable thing about this example, although the flow
of control of the original is clear, it is my experience that even very
good programmers often mess up in trying to eliminate the pesky goto :-)

The feeling of the goto here is something like what a musician means when
they say "take it from the top". So you have to be aiming at something 
similar when you remove the goto. I usually find that the introduction of
boolean flags obfuscates code, so if I was in a language like Bliss where
I could not use a goto, my taste is for the solution that resets the loop 
index (similar to what Patrick suggested). Here it is in Ada:

   J := 1;
   while J < N loop
      if D (J) > D (J + 1) then
         Swap (D (J), D (J + 1));
         J := 1;
      else
         J := J + 1;
      end if;
   end loop;

There are two reasons why, for my taste, this is less clear than the goto.

First: the critical "take it from the top" is buried inside the inner loop
as the assignment J := 1, whereas the label on the loop in my original
version shows right away that something strange is going on.

Second: I prefer the for loop to the while loop to give the sense of
running through the array in the inner loop. I really think of this algorithm
as being two nested loops, and I like the code to show this structure. The
above statement meshes the two loops together in what for me is a more
confusing form than the original.

Once again, if your taste is to prefer the J:=1 form because it is clearer,
that's fine, but please don't think that you can measure clarity by counting
gotos, and avoid the knee-jerk reaction that the form without a goto is
necessarily clearer.

Re: Why C++ is successful

[Rick Smith]

Robert Dewar wrote in message ...
>Robert Martin said
>
>  When I need to write a quick sort, and don't have access to a
>  decent sort function, then I prefer this simple structure...
>
[...]
>
>First of all, there is nothing "indecent" about the algorithm that I gave.
It
>has the merit of being by far the shortest sorting algorithm in generated
>code. Yes, it is slow (cubic) but for small numbers who cares, and byt the
>way it is optimal for already sorted data (it will outperform bubble sort
>or simple selection sort in such a setting, because of less control
overhead).
>
>As to the above algorithm, I actually find it far more contorted. I dislike
>the use of a flag that is tested on every loop to avoid an exit, but I
>perfectly well understand that some people prefer very clear preconditions
>on loops and do not like exits at all. Too bad that almost no compilers are
>clever enough to remove the additional overhead from this approach ....
>
>But the important thing is that the above algorithm is not at all the same
>as what I presented. I did not intend to start a thread on what is or is
not
>the best sorting algorithm, but rather to present an example of a simple
>non-finite-state machine case where many people wlil find the goto clearer.
>
>I trust that Robert Martin is not under the impression that the code above
>is equivalent computationally (i.e. same sequence of comparisons) as what
>I presented!
>
I prefer

    sort D ascending

no flag, no goto, no exit, no loop, and no chance of using the wrong
comparison operator. It does have the overhead of a library call; but it is
always available.
------------------
Rick Smith
e-mail: < ricksmith@aiservices.com >

Re: Why C++ is successful

[Patrick Doyle]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

In article <6r631r$5ph$1@platane.wanadoo.fr>,
Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote:
>Patrick Doyle a �crit dans le message ...
>>
>>Except that, if I understand this correctly, the outer loop
>>never terminates!  :-)
>As did the example...

No, the example did indeed terminate.  All that was required was
for the "for" loop to go through wach element of the list without
ever satisfying the "if" statement.  In that case, the for loop would
just terminate.  This occurs when the list is sorted.

>>Actually, this is not a trivial matter because the original point
>>was about having to add flags, and that's exactly what you'd have to
>>do to make this outer look exit.
>
>Certainly not. I just need to put a label Outer: on it, and a statement
>"exit outer" at any place where I discover that the array is sorted.

What you're going here is using the word "exit" where the rest of
us are using "goto".  Once you alter your code so that it does
the same as the original example, I think you'll find that it is
in fact the same code.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.toronto.edu

Re: Why C++ is successful

[Patrick Doyle]

In article <dewar.903279048@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>First the hint is simply because, although the algorithmic flow of the
>original is completely clear, 

Er, that is still under debate...  :-)

>it is my experience that when people
>contort to remove the gotos, they often end up with a non-equivalent
>algorithm. That says nothing about the clarity of the original, merely
>the difficulty of removing the goto.

Ok, I'll agree with that.  On the other hand, I find my own code
clearer if I just don't put the gotos in there in the first place.

>The above code is correct, but for my taste not clearer. I don't like
>having a loop which at the outside looks like a perfectly normal
>J from 1 .. N - 1 loop, but is not.

Ironically, that's exactly why I prefer my version.  Yours is based
on a for-loop.  If that does not suggest a once-through pass over
each element of the list, I don't know what does.  On the other
hand, mine is essentially a while-loop, which (to me) always suggests
that the pattern of iteration is more complex than a for-loop,
or else it should have been coded as one.

(Incidentally, there is no for-loop in Eiffel, so everything
must be coded as a while loop, but that is beside the point.) 

>Here the unusual structure of this loop is buried in an inner assignment,
>rather than being evident at the top level in my presentation with a goto.

Your goto was not at the top level.  The label was.  A label suggests
only that the indicated statement is the target of a jump.  It
makes no suggestion as to where this jump comes from; and to me,
it certainly doesn't suggest that a for-loop is no longer a for-loop.

>But certainly people differ in tastes and perhaps some will prefer the
>above, but please prefer it because it is clearer to you, NOT, as is the
>case for so many programmers, simply because the goto is eliminated.

Agreed.  Please take all my above comments as personal opinion only.

>There is nothing inherently unclear about a goto, that's the important
>thing. On the contrary, the semantics of a goto, intepreted in the normal
>operational manner at which most programmers interpret semantics, is 
>about as simple as it could be. Yes, of course it is possible to abuse
>the goto and write disgusting code, but the same can be said about
>any feature in any language.

The clarity of the goto statement is one of a number of examples
of paradoxical situations where the properties of a language
feature on a small scale are the opposite of its properties
on a large scale.

For example, a class declaration appears, on a small scale, to
add verbosity and complexity to code; but for large-scale software
construction, it has a powerful simplifying and clarifying
effect.

Likewise, while the goto is extremely simple on a micro-level, in
large-scale software it has precisely the opposite effect.  In
other words, it is easy to understand what the goto statement
does, but it's hard to understand what a large piece of code
based on gotos does.

But, as you say, this is just my (and Dijkstra's :-) opinion.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.toronto.edu

Re: Why C++ is successful

[Patrick Doyle]

In article <dewar.903279184@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>A postscript by the way is that I am not clear as to what language is
>being used for the above code, but I am assuming that, unlike the case
>in many languages, the until test is simply a negative while, and not
>a test at the end of the loop. A test at the end of the loop is of
>course quite incorrect. 

The language is Eiffel.  The test is performed at the start of each
iteration.

>Personally I don't like using until as the
>negation of while, since it is so well established by custom that
>until means an end of the loop test.

Fair enough.  I tend to think that the fact that the test comes before
the loop body makes the order of execution fairly self-evident.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.toronto.edu

Re: Why C++ is successful

[Robert Martin]

Robert Dewar wrote in message ...
>Robert Martin said
>
>  When I need to write a quick sort, and don't have access to a
>  decent sort function, then I prefer this simple structure...
>
>  bool unsorted = true;
>  for (int i=0; unsorted && i<(N-1); i++)
>  {
>    unsorted = false;
>    for (int j = 0; j<(N-i-1); j++)
>    {
>      if (d[j] > d[j+1])
>      {
>        swap(d, j);
>        unsorted = true;
>      }
>    }
>  }
>
>First of all, there is nothing "indecent" about the algorithm that I gave.

Sorry, I didn't mean to offend you; nor am I interested in starting a 'sort'
war.  The point I was trying to make was: why write it if you have a library
that already has a better one?

>I trust that Robert Martin is not under the impression that the code above
>is equivalent computationally (i.e. same sequence of comparisons) as what
>I presented!

Nope, I was just showing the function that I prefer.  Since I am familiar
with it, I find it more understandable then the one you wrote.  But that's
just me.

Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: Why C++ is successful

[Robert Dewar]

Rick Smith said

<<I prefer

    sort D ascending

no flag, no goto, no exit, no loop, and no chance of using the wrong
comparison operator. It does have the overhead of a library call; but it is
always available.
>>

Sure, but that has nothing at all to do with the point I was making. Once
again, the discussoin here is not about sorting algorithms, but about how
to represent a particular algorithm!

Re: Why C++ is successful

[Jean-Pierre Rosen]

Robert Dewar a �crit dans le message ...
>JPR says
>
><<Certainly not. I just need to put a label Outer: on it, and a statement
>"exit outer" at any place where I discover that the array is sorted.
>>>
>
>Kindly then, please do so, we know the principles, the point is the
example.
>You posted a program that was syntactically incorrect, and also contained
>a fundamental semantic error. It is not so easy asyou think to avoid the
>flag here, please try -- don't just say you can do it without proving it!
OK, I confess I responded a bit hastilly (as proven by the obvious syntax
error). I focused on the case when the goto was executed, and forgot the
other one...

Now, just for fun, I'll give it a try anyway. Well, the original was:


<<Sort>> for J in 1 .. N - 1 loop
       if D (J) > D (J + 1) then
          Swap (D(J), D(J + 1));
          goto Sort;
       end if;

Obviously, we need to terminate the algorithm if we go to the end of the
loop. This woud translate as:
Outer: loop
   Inner: for J in 1 .. N - 1 loop
       if D (J) > D (J + 1) then
          Swap (D(J), D(J + 1));
          exit Inner;
       end if;
       if J = N-1 then
          exit Outer;
       end if;
   end loop Inner;
end loop Outer;

but of course, we add a spurious test in the inner loop, and I hate testing
for special values of the loop variable (sorry, constant!) in the body of
the loop. Actually, what we miss here is an exit from a *block*, but we can
use an extra loop to the same effect:

Outer: loop
   Restart : loop
      for J in 1 .. N - 1 loop
          if D (J) > D (J + 1) then
             Swap (D(J), D(J + 1));
             exit Restart;
          end if;
      end loop;
      exit Outer;
   end loop Restart;
end loop Outer;

OK, you asked me to prove it was feasible, I think I did (unless I missed
another obvious point, I'd better be careful now :-).
Now, don't tell me it's a lot of baggage for the sake of avoiding a goto, I
agree.

Re: Why C++ is successful

[Rick Smith]

Robert Dewar wrote in message ...
>Rick Smith said
>
><<I prefer
>
>    sort D ascending
>
>no flag, no goto, no exit, no loop, and no chance of using the wrong
>comparison operator. It does have the overhead of a library call; but it is
>always available.
>>>
>
>Sure, but that has nothing at all to do with the point I was making. Once
>again, the discussoin here is not about sorting algorithms, but about how
>to represent a particular algorithm!
>
1. You were making a point that the use of goto in Ada *may* be
    clearer that methods not using goto.
2. You stated that you "dislike the use of a flag that is tested
    on every loop."
3. You posted to several non-Ada groups; therefore opening the
    discussion to other languages. ;-)

The COBOL example I gave is, IMO, much clearer than methods using
goto or flags, in any other language. (comp.software-eng)

Though not as clear as using an ordered collection, which avoids the
(explicit inclusion of a) sort. (comp.object)

I fail to see how your earlier statement (or my response!) is relevant to
the subject of this thread!
---------------------
Rick Smith
e-mail: < ricksmith@aiservices.com >

Re: Why C++ is successful

[Robert I. Eachus]

In article <vUQA1.451$_P3.515571824@newsreader.digex.net> Ell <ell@access2.digex.net> writes:

 > How about to avoid procedure call stack winding and unwinding in time
 > critical code?

    Nope, in Ada you use pragma Inline for that.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Why C++ is successful

[Patrick Logan]

In comp.object Robert I. Eachus <eachus@spectre.mitre.org> wrote:

:  > How about to avoid procedure call stack winding and unwinding in time
:  > critical code?

:     Nope, in Ada you use pragma Inline for that.

Another approach is to use a compiler that can eliminate tail
recursive stack growth. If function A returns the result of function
B, then there is no need to increase the stack only to pop it when the
call is done. The result is a procedure call can be compiled as
efficiently as a GOTO. Scheme is defined this way. All iterations can
be defined in terms of procedures.

The gcc compiler makes these eliminations as well. It also defines
local procedure definitions for C, perhaps making the use of
procedures instead of loops more attractive. But I have never seen
what this extension looks like.

-- 
Patrick Logan    (H) mailto:plogan@teleport.com 
                 (W) mailto:patrickl@gemstone.com 
                 http://www.gemstone.com

Re: Why C++ is successful

[Samuel Tardieu]

Robert> How about to avoid procedure call stack winding and unwinding
Robert> in time critical code?

Patrick> Another approach is to use a compiler that can eliminate tail
Patrick> recursive stack growth. If function A returns the result of
Patrick> function B, then there is no need to increase the stack only
Patrick> to pop it when the call is done. The result is a procedure
Patrick> call can be compiled as efficiently as a GOTO. Scheme is
Patrick> defined this way. All iterations can be defined in terms of
Patrick> procedures.

GNAT also makes this optimization for tail recursive functions.

For example, the following code:

   function Even (N : Natural) return Boolean is
   begin
      if N = 0 then
         return True;
      elsif N = 1 then
         return False;
      else
         return Even (N - 2);
      end if;
   end Even;

will be compiled as (flags used: -O3 -gnatp -fomit-frame-pointer) on a 
pentium:

_ada_even:
	movl 4(%esp),%eax
.L5:
	testl %eax,%eax
	jne .L2
	movb $1,%al
	ret
	.align 4
.L2:
	cmpl $1,%eax
	je .L4
	addl $-2,%eax
	jmp .L5
	.align 4
.L4:
	xorl %eax,%eax
	ret

Note that there is no subprogram call to Even from whithin Even, which
means that the stack will not grow as recursive calls are made.

In fact, GCC's back end transform the program flow to look like:

   function Even (N : Natural) return Boolean is
      C : Natural := N;
   begin
    << Even_Begin >>
      if C = 0 then
         return True;
      elsif C = 1 then
         return False;
      else
         C := C - 2;
         goto Even_Begin;
      end if;
   end Even;

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Why C++ is successful

[Martin Tom Brown]

On 16 Aug, in article <dewar.903279048@merv>
     dewar@merv.cs.nyu.edu "Robert Dewar" wrote:

> Patrick said
> 
>   Well, the fact that you had to add that hint suggests something about
>   your code's clarity...  :-)
> 
>   How about this:
> 
>   from
>           J := 1
>   until
>           J >= N
>   loop
>           if D(J) > D(J+1) then
>                   Swap (D(J), D(J+1));
>                   J := 1;
>           else
>                   J := J + 1;
>           end
>   end
> 
> First the hint is simply because, although the algorithmic flow of the
> original is completely clear, it is my experience that when people
> contort to remove the gotos, they often end up with a non-equivalent
> algorithm.

I would argue that the above is clearer and easier to understand
in that it now becomes obvious that after every swap at J  
the stated algorithm will do  J-1 redundant comparisons.
(and the "refinement" to bubble sort becomes obvious)

> That says nothing about the clarity of the original, merely
> the difficulty of removing the goto.

Using a goto to jump back to the start of a for loop is exceptionally ugly.
Somehow it looks more like an entry for an obfuscated code contest.

> The above code is correct, but for my taste not clearer. I don't like
> having a loop which at the outside looks like a perfectly normal
> J from 1 .. N - 1 loop, but is not.

Tastes differ I guess. What is quite telling is that several attempts
to rewrite your original (even with a hint) have been completely wrong.
Some failing even to sort at all, others failing to terminate.

> Here the unusual structure of this loop is buried in an inner assignment,
> rather than being evident at the top level in my presentation with a goto.

I see your point. But still prefer the internal assignment version.

> But certainly people differ in tastes and perhaps some will prefer the
> above, but please prefer it because it is clearer to you, NOT, as is the
> case for so many programmers, simply because the goto is eliminated.

Clarity is in the eye of the beholder. Circumstantial evidence here
has been that the original version though correct was opaque to a
fair proportion of readers. Imagine a large program in that style...

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Why C++ is successful

[Don Harrison]

Nasser wrote (on uses of gotos):

:what about a common exit for a function?
:
:as we all know (offcourse :) that a function should have one
:common exit. ..

Yes.  :)

:sometime it is easier to go to a common_exit label at the bottom
:of the function, where some common cleanup can be done if needed,
:rather than use a nested if then else to try to carry the logic
:through all the way down. 
:
:example:
:
:   if status /= good then
:      goto common_exit;
:   end if;
:
:   status = do_soemthing;
:
:   if status /= good then
:      goto common_exit;
:    end if;
:
:    status = do_another_thing
:
:    etc..
:
:<<common_exit>>
:    return status;  -- or log error message if status not good..etc..
:
:
:without a goto, one has to do:
:
:example:
:
:   if status = good then
:      status = do_somtehing;
:      if status = good then
:         status = do_another_thing
:      else
:         etc..  -- error
:       end if;
:   else
:      ..  -- error
:   end if;

Do you? The following should give you what you need without resorting 
to gotos or ugly indentation:

   for Try in 1 .. No_of_Tries loop
       case Try is
       when 1 =>
           Status := Function_1;
       when 2 =>
           Status := Function_2;
       ...
       when No_of_Tries =>
           Status := Function_No_of_Tries;
       end case;

       if Status = Good then
           exit;
       end if;

    end loop;

    if Status = Good then
        return Status;
    else
        Log_Error (..);
        raise Postcondition_Error;  -- failed to get a result
    end if;


Don.
Don Harrison   donh at syd.csa.com.au

Re: Why C++ is successful

[dewar]

<<Clarity is in the eye of the beholder. Circumstantial evidence here.uk>
has been that the original version though correct was opaque to a
fair proportion of readers.>>

The readers who produced wrong solutions wrote complete
nonsense, in one case
the program was not even compiled, and had an evident infinite loop. I
do not think that either of thes proved anything about the original,
but I do think that it showed that it is easy to mess up the attempt
to do this in a goto free manner. Actually I find it very odd that
USA programmers are so allergic to gotos.

<<Imagine a large program in that style... >>

But that's a meaningless argument. Arguing that you don't like someone's
green suit because it would be horrible if everyone wore green makes no
sense. No one is arguing for wide spread use of gotos in large programs,
so it is a useless rhetorical device to argue against this :-)

Perhaps the comment about goto-holic is the right comment. Those of us
who learned to program in a reasonable environment of Algol and Simula,
always knew that gotos were seldom needed. The most amazing thing about
EWD's letter, which merely pointed out an obvious fact known to all
competent programmers for a decade before his letter was printed, was
the huge reaction to it.

I think that the problem was that a generation brought up on Forgtran
and Basic, had never understood the idea that goto was something to be
used only occasionally.

So people avoid gotos very much like an alcoholic avoiding alcohol.
Sometimes even in a ludicrous manner, I have often seen COBOL programs
that did a PERFORM on a procedure that ended with STOP RUN, an obviously
bad choice compared to a GOTO (you can see the same thing in C where people
would never use a goto, but are happy to use exit).

Note as an example that in the book ALgorithms + Data structures = Programs
(or whatever the exact title is), Wirth is quite happy to use an occasional
goto when he feels that it will clarify the code. Certainly I would expect
EWD to be perfectly happy with Wirth's code in this book.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum