* Re: Bug story
[not found] ` <35B60AC4.D703E836@hso.link.com>
@ 1998-07-25 0:00 ` Fergus Henderson
1998-07-29 0:00 ` Robert I. Eachus
0 siblings, 1 reply; 101+ messages in thread
From: Fergus Henderson @ 1998-07-25 0:00 UTC (permalink / raw)
"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.
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Bug story
1998-07-25 0:00 ` Bug story Fergus Henderson
@ 1998-07-29 0:00 ` Robert I. Eachus
0 siblings, 0 replies; 101+ messages in thread
From: Robert I. Eachus @ 1998-07-29 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 101+ messages in thread
[parent not found: <6p83vj$657$1@news.intellistor.com>]
* Re: Why C++ is successful
@ 1998-08-06 0:00 Robert Dewar
1998-08-06 0:00 ` William Clodius
1998-08-06 0:00 ` Martin Dowie
0 siblings, 2 replies; 101+ messages in thread
From: Robert Dewar @ 1998-08-06 0:00 UTC (permalink / raw)
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???
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-06 0:00 Robert Dewar
@ 1998-08-06 0:00 ` William Clodius
1998-08-06 0:00 ` Martin Dowie
1 sibling, 0 replies; 101+ messages in thread
From: William Clodius @ 1998-08-06 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-06 0:00 Robert Dewar
1998-08-06 0:00 ` William Clodius
@ 1998-08-06 0:00 ` Martin Dowie
1 sibling, 0 replies; 101+ messages in thread
From: Martin Dowie @ 1998-08-06 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
@ 1998-08-06 0:00 Robert Dewar
1998-08-07 0:00 ` harald.mueller
1998-08-07 0:00 ` Jason Stokes
0 siblings, 2 replies; 101+ messages in thread
From: Robert Dewar @ 1998-08-06 0:00 UTC (permalink / raw)
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!)
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-06 0:00 Robert Dewar
@ 1998-08-07 0:00 ` harald.mueller
1998-08-07 0:00 ` Brian Rogoff
1998-08-07 0:00 ` Robert Dewar
1998-08-07 0:00 ` Jason Stokes
1 sibling, 2 replies; 101+ messages in thread
From: harald.mueller @ 1998-08-07 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-07 0:00 ` harald.mueller
@ 1998-08-07 0:00 ` Brian Rogoff
1998-08-07 0:00 ` Timothy Welch
1998-08-07 0:00 ` Robert Dewar
1 sibling, 1 reply; 101+ messages in thread
From: Brian Rogoff @ 1998-08-07 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-07 0:00 ` Brian Rogoff
@ 1998-08-07 0:00 ` Timothy Welch
1998-08-08 0:00 ` Robert Dewar
1998-08-08 0:00 ` Dale Stanbrough
0 siblings, 2 replies; 101+ messages in thread
From: Timothy Welch @ 1998-08-07 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-07 0:00 ` Timothy Welch
@ 1998-08-08 0:00 ` Robert Dewar
1998-08-08 0:00 ` Jeffrey C. Dege
` (2 more replies)
1998-08-08 0:00 ` Dale Stanbrough
1 sibling, 3 replies; 101+ messages in thread
From: Robert Dewar @ 1998-08-08 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-08 0:00 ` Robert Dewar
@ 1998-08-08 0:00 ` Jeffrey C. Dege
1998-08-08 0:00 ` Patrick Logan
` (2 more replies)
1998-08-08 0:00 ` Phlip
1998-08-08 0:00 ` Larry Elmore
2 siblings, 3 replies; 101+ messages in thread
From: Jeffrey C. Dege @ 1998-08-08 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-08 0:00 ` Jeffrey C. Dege
@ 1998-08-08 0:00 ` Patrick Logan
1998-08-10 0:00 ` Laurent GUERBY
1998-08-11 0:00 ` stilcom
2 siblings, 0 replies; 101+ messages in thread
From: Patrick Logan @ 1998-08-08 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-08 0:00 ` Jeffrey C. Dege
1998-08-08 0:00 ` Patrick Logan
@ 1998-08-10 0:00 ` Laurent GUERBY
1998-08-12 0:00 ` Andy Ward
1998-08-11 0:00 ` stilcom
2 siblings, 1 reply; 101+ messages in thread
From: Laurent GUERBY @ 1998-08-10 0:00 UTC (permalink / raw)
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)."
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-10 0:00 ` Laurent GUERBY
@ 1998-08-12 0:00 ` Andy Ward
1998-08-12 0:00 ` Matt Kennel
1998-08-14 0:00 ` Robert Dewar
0 siblings, 2 replies; 101+ messages in thread
From: Andy Ward @ 1998-08-12 0:00 UTC (permalink / raw)
> 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.
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-12 0:00 ` Andy Ward
@ 1998-08-12 0:00 ` Matt Kennel
1998-08-14 0:00 ` Robert Dewar
1 sibling, 0 replies; 101+ messages in thread
From: Matt Kennel @ 1998-08-12 0:00 UTC (permalink / raw)
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?'"
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-12 0:00 ` Andy Ward
1998-08-12 0:00 ` Matt Kennel
@ 1998-08-14 0:00 ` Robert Dewar
1998-08-13 0:00 ` nasser
` (3 more replies)
1 sibling, 4 replies; 101+ messages in thread
From: Robert Dewar @ 1998-08-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-14 0:00 ` Robert Dewar
@ 1998-08-13 0:00 ` nasser
1998-08-19 0:00 ` Don Harrison
1998-08-14 0:00 ` Patrick Doyle
` (2 subsequent siblings)
3 siblings, 1 reply; 101+ messages in thread
From: nasser @ 1998-08-13 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-13 0:00 ` nasser
@ 1998-08-19 0:00 ` Don Harrison
0 siblings, 0 replies; 101+ messages in thread
From: Don Harrison @ 1998-08-19 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-14 0:00 ` Robert Dewar
1998-08-13 0:00 ` nasser
@ 1998-08-14 0:00 ` Patrick Doyle
1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Robert Dewar
1998-08-14 0:00 ` Jean-Pierre Rosen
1998-08-14 0:00 ` Ell
3 siblings, 2 replies; 101+ messages in thread
From: Patrick Doyle @ 1998-08-14 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-14 0:00 ` Patrick Doyle
@ 1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Patrick Doyle
1998-08-16 0:00 ` Robert Dewar
1 sibling, 1 reply; 101+ messages in thread
From: Robert Dewar @ 1998-08-16 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-16 0:00 ` Robert Dewar
@ 1998-08-16 0:00 ` Patrick Doyle
0 siblings, 0 replies; 101+ messages in thread
From: Patrick Doyle @ 1998-08-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-14 0:00 ` Patrick Doyle
1998-08-16 0:00 ` Robert Dewar
@ 1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Patrick Doyle
1998-08-18 0:00 ` Martin Tom Brown
1 sibling, 2 replies; 101+ messages in thread
From: Robert Dewar @ 1998-08-16 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-16 0:00 ` Robert Dewar
@ 1998-08-16 0:00 ` Patrick Doyle
1998-08-18 0:00 ` Martin Tom Brown
1 sibling, 0 replies; 101+ messages in thread
From: Patrick Doyle @ 1998-08-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Patrick Doyle
@ 1998-08-18 0:00 ` Martin Tom Brown
1 sibling, 0 replies; 101+ messages in thread
From: Martin Tom Brown @ 1998-08-18 0:00 UTC (permalink / raw)
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 /^,,)__/
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-14 0:00 ` Robert Dewar
1998-08-13 0:00 ` nasser
1998-08-14 0:00 ` Patrick Doyle
@ 1998-08-14 0:00 ` Jean-Pierre Rosen
1998-08-14 0:00 ` Robert Martin
` (3 more replies)
1998-08-14 0:00 ` Ell
3 siblings, 4 replies; 101+ messages in thread
From: Jean-Pierre Rosen @ 1998-08-14 0:00 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-14 0:00 ` Jean-Pierre Rosen
@ 1998-08-14 0:00 ` Robert Martin
1998-08-16 0:00 ` Robert Dewar
1998-08-15 0:00 ` Patrick Doyle
` (2 subsequent siblings)
3 siblings, 1 reply; 101+ messages in thread
From: Robert Martin @ 1998-08-14 0:00 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-14 0:00 ` Robert Martin
@ 1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Rick Smith
1998-08-16 0:00 ` Robert Martin
0 siblings, 2 replies; 101+ messages in thread
From: Robert Dewar @ 1998-08-16 0:00 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-16 0:00 ` Robert Dewar
@ 1998-08-16 0:00 ` Rick Smith
1998-08-17 0:00 ` Robert Dewar
1998-08-16 0:00 ` Robert Martin
1 sibling, 1 reply; 101+ messages in thread
From: Rick Smith @ 1998-08-16 0:00 UTC (permalink / raw)
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 >
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-16 0:00 ` Rick Smith
@ 1998-08-17 0:00 ` Robert Dewar
1998-08-17 0:00 ` Rick Smith
0 siblings, 1 reply; 101+ messages in thread
From: Robert Dewar @ 1998-08-17 0:00 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-17 0:00 ` Robert Dewar
@ 1998-08-17 0:00 ` Rick Smith
0 siblings, 0 replies; 101+ messages in thread
From: Rick Smith @ 1998-08-17 0:00 UTC (permalink / raw)
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 >
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Rick Smith
@ 1998-08-16 0:00 ` Robert Martin
1 sibling, 0 replies; 101+ messages in thread
From: Robert Martin @ 1998-08-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-14 0:00 ` Jean-Pierre Rosen
1998-08-14 0:00 ` Robert Martin
@ 1998-08-15 0:00 ` Patrick Doyle
1998-08-15 0:00 ` Jean-Pierre Rosen
1998-08-15 0:00 ` Mr Ada
1998-08-16 0:00 ` Robert Dewar
3 siblings, 1 reply; 101+ messages in thread
From: Patrick Doyle @ 1998-08-15 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-15 0:00 ` Patrick Doyle
@ 1998-08-15 0:00 ` Jean-Pierre Rosen
1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Patrick Doyle
0 siblings, 2 replies; 101+ messages in thread
From: Jean-Pierre Rosen @ 1998-08-15 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-15 0:00 ` Jean-Pierre Rosen
@ 1998-08-16 0:00 ` Robert Dewar
1998-08-17 0:00 ` Jean-Pierre Rosen
1998-08-16 0:00 ` Patrick Doyle
1 sibling, 1 reply; 101+ messages in thread
From: Robert Dewar @ 1998-08-16 0:00 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-16 0:00 ` Robert Dewar
@ 1998-08-17 0:00 ` Jean-Pierre Rosen
0 siblings, 0 replies; 101+ messages in thread
From: Jean-Pierre Rosen @ 1998-08-17 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-15 0:00 ` Jean-Pierre Rosen
1998-08-16 0:00 ` Robert Dewar
@ 1998-08-16 0:00 ` Patrick Doyle
1 sibling, 0 replies; 101+ messages in thread
From: Patrick Doyle @ 1998-08-16 0:00 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-14 0:00 ` Jean-Pierre Rosen
1998-08-14 0:00 ` Robert Martin
1998-08-15 0:00 ` Patrick Doyle
@ 1998-08-15 0:00 ` Mr Ada
1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Robert Dewar
3 siblings, 1 reply; 101+ messages in thread
From: Mr Ada @ 1998-08-15 0:00 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-15 0:00 ` Mr Ada
@ 1998-08-16 0:00 ` Robert Dewar
0 siblings, 0 replies; 101+ messages in thread
From: Robert Dewar @ 1998-08-16 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-14 0:00 ` Jean-Pierre Rosen
` (2 preceding siblings ...)
1998-08-15 0:00 ` Mr Ada
@ 1998-08-16 0:00 ` Robert Dewar
3 siblings, 0 replies; 101+ messages in thread
From: Robert Dewar @ 1998-08-16 0:00 UTC (permalink / raw)
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 ...
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-14 0:00 ` Robert Dewar
` (2 preceding siblings ...)
1998-08-14 0:00 ` Jean-Pierre Rosen
@ 1998-08-14 0:00 ` Ell
1998-08-17 0:00 ` Robert I. Eachus
3 siblings, 1 reply; 101+ messages in thread
From: Ell @ 1998-08-14 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-14 0:00 ` Ell
@ 1998-08-17 0:00 ` Robert I. Eachus
1998-08-17 0:00 ` Patrick Logan
0 siblings, 1 reply; 101+ messages in thread
From: Robert I. Eachus @ 1998-08-17 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-17 0:00 ` Robert I. Eachus
@ 1998-08-17 0:00 ` Patrick Logan
1998-08-18 0:00 ` Samuel Tardieu
0 siblings, 1 reply; 101+ messages in thread
From: Patrick Logan @ 1998-08-17 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-17 0:00 ` Patrick Logan
@ 1998-08-18 0:00 ` Samuel Tardieu
0 siblings, 0 replies; 101+ messages in thread
From: Samuel Tardieu @ 1998-08-18 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-08 0:00 ` Jeffrey C. Dege
1998-08-08 0:00 ` Patrick Logan
1998-08-10 0:00 ` Laurent GUERBY
@ 1998-08-11 0:00 ` stilcom
1998-08-12 0:00 ` Jeffrey C. Dege
2 siblings, 1 reply; 101+ messages in thread
From: stilcom @ 1998-08-11 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-11 0:00 ` stilcom
@ 1998-08-12 0:00 ` Jeffrey C. Dege
1998-08-12 0:00 ` Andrew Koenig
1998-08-14 0:00 ` Stefan Tilkov
0 siblings, 2 replies; 101+ messages in thread
From: Jeffrey C. Dege @ 1998-08-12 0:00 UTC (permalink / raw)
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."
^ permalink raw reply [flat|nested] 101+ messages in thread* Re: Why C++ is successful
1998-08-12 0:00 ` Jeffrey C. Dege
@ 1998-08-12 0:00 ` Andrew Koenig
1998-08-14 0:00 ` Stefan Tilkov
1 sibling, 0 replies; 101+ messages in thread
From: Andrew Koenig @ 1998-08-12 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-12 0:00 ` Jeffrey C. Dege
1998-08-12 0:00 ` Andrew Koenig
@ 1998-08-14 0:00 ` Stefan Tilkov
1 sibling, 0 replies; 101+ messages in thread
From: Stefan Tilkov @ 1998-08-14 0:00 UTC (permalink / raw)
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."
>
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-08 0:00 ` Robert Dewar
1998-08-08 0:00 ` Jeffrey C. Dege
@ 1998-08-08 0:00 ` Phlip
1998-08-08 0:00 ` Larry Elmore
2 siblings, 0 replies; 101+ messages in thread
From: Phlip @ 1998-08-08 0:00 UTC (permalink / raw)
>...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 =======
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-08 0:00 ` Robert Dewar
1998-08-08 0:00 ` Jeffrey C. Dege
1998-08-08 0:00 ` Phlip
@ 1998-08-08 0:00 ` Larry Elmore
2 siblings, 0 replies; 101+ messages in thread
From: Larry Elmore @ 1998-08-08 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-07 0:00 ` Timothy Welch
1998-08-08 0:00 ` Robert Dewar
@ 1998-08-08 0:00 ` Dale Stanbrough
1 sibling, 0 replies; 101+ messages in thread
From: Dale Stanbrough @ 1998-08-08 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-07 0:00 ` harald.mueller
1998-08-07 0:00 ` Brian Rogoff
@ 1998-08-07 0:00 ` Robert Dewar
1998-08-08 0:00 ` Patrick Logan
1 sibling, 1 reply; 101+ messages in thread
From: Robert Dewar @ 1998-08-07 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-07 0:00 ` Robert Dewar
@ 1998-08-08 0:00 ` Patrick Logan
0 siblings, 0 replies; 101+ messages in thread
From: Patrick Logan @ 1998-08-08 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-06 0:00 Robert Dewar
1998-08-07 0:00 ` harald.mueller
@ 1998-08-07 0:00 ` Jason Stokes
1998-08-08 0:00 ` Robert Dewar
1998-08-10 0:00 ` Darren New
1 sibling, 2 replies; 101+ messages in thread
From: Jason Stokes @ 1998-08-07 0:00 UTC (permalink / raw)
-----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-----
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-07 0:00 ` Jason Stokes
@ 1998-08-08 0:00 ` Robert Dewar
1998-08-10 0:00 ` Robert I. Eachus
1998-08-11 0:00 ` n
1998-08-10 0:00 ` Darren New
1 sibling, 2 replies; 101+ messages in thread
From: Robert Dewar @ 1998-08-08 0:00 UTC (permalink / raw)
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 :-)
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-08 0:00 ` Robert Dewar
@ 1998-08-10 0:00 ` Robert I. Eachus
1998-08-11 0:00 ` n
1 sibling, 0 replies; 101+ messages in thread
From: Robert I. Eachus @ 1998-08-10 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-08 0:00 ` Robert Dewar
1998-08-10 0:00 ` Robert I. Eachus
@ 1998-08-11 0:00 ` n
1998-08-14 0:00 ` Robert Dewar
1 sibling, 1 reply; 101+ messages in thread
From: n @ 1998-08-11 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-11 0:00 ` n
@ 1998-08-14 0:00 ` Robert Dewar
[not found] ` <35D455AC.9225EAA7@hercii.mar.lmco.com>
0 siblings, 1 reply; 101+ messages in thread
From: Robert Dewar @ 1998-08-14 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
1998-08-07 0:00 ` Jason Stokes
1998-08-08 0:00 ` Robert Dewar
@ 1998-08-10 0:00 ` Darren New
1 sibling, 0 replies; 101+ messages in thread
From: Darren New @ 1998-08-10 0:00 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Why C++ is successful
@ 1998-08-22 0:00 dewar
0 siblings, 0 replies; 101+ messages in thread
From: dewar @ 1998-08-22 0:00 UTC (permalink / raw)
<<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
^ permalink raw reply [flat|nested] 101+ messages in thread
end of thread, other threads:[~1998-08-22 0:00 UTC | newest]
Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <35AE4621.2EBC7F6A@eiffel.com>
[not found] ` <7hAr1.3249$9E2.2188373@news.teleport.com>
[not found] ` <35AF70B9.61C5BF88@oma.com>
[not found] ` <N.19980718.jjru@sisyphus.demon.co.uk>
[not found] ` <35B32BDC.5C2C@dmu.ac.uk>
[not found] ` <N.19980720.ulio@sisyphus.demon.co.uk>
[not found] ` <35B47EAD.3AA9@dmu.ac.uk>
[not found] ` <N.19980722.gwka@sisyphus.demon.co.uk>
[not found] ` <35B60AC4.D703E836@hso.link.com>
1998-07-25 0:00 ` Bug story Fergus Henderson
1998-07-29 0:00 ` Robert I. Eachus
[not found] ` <6p83vj$657$1@news.intellistor.com>
[not found] ` <35B79E7D.6068DCDF@eiffel.com>
[not found] ` <6pg7fg$qhi$1@news.interlog.com>
[not found] ` <901533851.20058.0.nnrp-04.9e980ba3@news.demon.co.uk>
[not found] ` <35be2a94.57352308@netnews.msn.com>
1998-07-28 0:00 ` Why C++ is successful Rakesh Malhotra
1998-07-29 0:00 ` Tom Moran
1998-07-29 0:00 ` Ell
1998-07-29 0:00 ` Tom Moran
1998-07-29 0:00 ` Ell
1998-07-29 0:00 ` Dave Martin
1998-07-29 0:00 ` Pat Rogers
1998-07-29 0:00 ` Juan Carlos Gil Montoro
1998-07-29 0:00 ` Pat Rogers
1998-07-29 0:00 ` Jay Martin
1998-07-30 0:00 ` dennison
1998-07-30 0:00 ` Ell
1998-07-29 0:00 ` Pat Rogers
1998-07-30 0:00 ` Ell
1998-07-30 0:00 ` Ell
1998-07-29 0:00 ` Larry Elmore
1998-07-30 0:00 ` Ell
1998-07-30 0:00 ` Jeffrey C. Dege
1998-08-01 0:00 ` Robert Dewar
1998-07-29 0:00 ` Brian Rogoff
1998-07-29 0:00 ` John McCabe
1998-07-29 0:00 ` Charles Hixson
1998-07-29 0:00 ` falis
1998-07-30 0:00 ` Robert I. Eachus
1998-07-31 0:00 ` Charles Hixson
1998-08-01 0:00 ` Jay Martin
1998-08-02 0:00 ` Robert Dewar
1998-08-01 0:00 ` Jay Martin
1998-08-02 0:00 ` Matthew Heaney
1998-08-02 0:00 ` Jay Martin
1998-08-02 0:00 ` Matthew Heaney
1998-08-02 0:00 ` Matthew Heaney
1998-08-02 0:00 ` Lars Farm
1998-08-02 0:00 ` Matthew Heaney
1998-08-02 0:00 ` Lars Farm
1998-08-10 0:00 ` Robert I. Eachus
1998-07-29 0:00 ` Jean-Pierre Rosen
1998-07-29 0:00 ` Rakesh Malhotra
1998-07-29 0:00 ` John McCabe
1998-07-29 0:00 ` nabbasi
1998-08-08 0:00 ` Michael Young
1998-08-06 0:00 Robert Dewar
1998-08-06 0:00 ` William Clodius
1998-08-06 0:00 ` Martin Dowie
-- strict thread matches above, loose matches on Subject: below --
1998-08-06 0:00 Robert Dewar
1998-08-07 0:00 ` harald.mueller
1998-08-07 0:00 ` Brian Rogoff
1998-08-07 0:00 ` Timothy Welch
1998-08-08 0:00 ` Robert Dewar
1998-08-08 0:00 ` Jeffrey C. Dege
1998-08-08 0:00 ` Patrick Logan
1998-08-10 0:00 ` Laurent GUERBY
1998-08-12 0:00 ` Andy Ward
1998-08-12 0:00 ` Matt Kennel
1998-08-14 0:00 ` Robert Dewar
1998-08-13 0:00 ` nasser
1998-08-19 0:00 ` Don Harrison
1998-08-14 0:00 ` Patrick Doyle
1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Patrick Doyle
1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Patrick Doyle
1998-08-18 0:00 ` Martin Tom Brown
1998-08-14 0:00 ` Jean-Pierre Rosen
1998-08-14 0:00 ` Robert Martin
1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Rick Smith
1998-08-17 0:00 ` Robert Dewar
1998-08-17 0:00 ` Rick Smith
1998-08-16 0:00 ` Robert Martin
1998-08-15 0:00 ` Patrick Doyle
1998-08-15 0:00 ` Jean-Pierre Rosen
1998-08-16 0:00 ` Robert Dewar
1998-08-17 0:00 ` Jean-Pierre Rosen
1998-08-16 0:00 ` Patrick Doyle
1998-08-15 0:00 ` Mr Ada
1998-08-16 0:00 ` Robert Dewar
1998-08-16 0:00 ` Robert Dewar
1998-08-14 0:00 ` Ell
1998-08-17 0:00 ` Robert I. Eachus
1998-08-17 0:00 ` Patrick Logan
1998-08-18 0:00 ` Samuel Tardieu
1998-08-11 0:00 ` stilcom
1998-08-12 0:00 ` Jeffrey C. Dege
1998-08-12 0:00 ` Andrew Koenig
1998-08-14 0:00 ` Stefan Tilkov
1998-08-08 0:00 ` Phlip
1998-08-08 0:00 ` Larry Elmore
1998-08-08 0:00 ` Dale Stanbrough
1998-08-07 0:00 ` Robert Dewar
1998-08-08 0:00 ` Patrick Logan
1998-08-07 0:00 ` Jason Stokes
1998-08-08 0:00 ` Robert Dewar
1998-08-10 0:00 ` Robert I. Eachus
1998-08-11 0:00 ` n
1998-08-14 0:00 ` Robert Dewar
[not found] ` <35D455AC.9225EAA7@hercii.mar.lmco.com>
1998-08-14 0:00 ` Robert L. Spooner
1998-08-10 0:00 ` Darren New
1998-08-22 0:00 dewar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox