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

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